Remove unneeded `padding` field from `MemoryDescriptor` struct

[liferooter]

The purpose of adding this field is to enforce correct alignment. But #[repr(C)] already enforces it.

Let's see structure alignment with and without this field:

With padding field:

pub struct MemoryDescriptor {
    // size: 4, alignment: 4, offset: 0
    pub ty: MemoryType,
    // size: 4, alignment: 4, offset: 4
    padding: u32,
    // size: 8, alignment: 8, offset: 8
    pub phys_start: PhysicalAddress,
    // size: 8, alignment: 8, offset: 16
    pub virt_start: VirtualAddress,
    // size: 8, alignment: 8, offset: 24
    pub page_count: u64,
    // size: 8, alignment: 8, offset: 32
    pub att: MemoryAttribute,
}

Without padding field:

pub struct MemoryDescriptor {
    // size: 4, alignment: 4, offset: 0
    pub ty: MemoryType,
    // size: 8, alignment: 8, offset: 8
    pub phys_start: PhysicalAddress,
    // size: 8, alignment: 8, offset: 16
    pub virt_start: VirtualAddress,
    // size: 8, alignment: 8, offset: 24
    pub page_count: u64,
    // size: 8, alignment: 8, offset: 32
    pub att: MemoryAttribute,
}

As you can see, these memory layouts are the same one. So there's no need for a useless private field that makes working with the type harder (e.g. you can't use structure declaration to create an instance of this struct). So I suggest to remove the padding field.

[nicholasbishop]

I agree the padding field seems unnecessary. I see you have a commit that removes it, please feel free to put up a PR in this repo.

[phip1611]

The question is if it is worth it to switch from an explicit approach to an implicit one. It increases the risk for future changes, theoretically. However, significant changes to this code are unlikely.

[nicholasbishop]

A couple arguments in favor of removing the padding:

• It matches what we do elsewhere for most structs; we typically don't explicitly specify padding fields.
• It matches how the struct is defined in the UEFI spec.

[phip1611]

Thanks for pointing that out.