Re: partition map reorganization

[Marco Gerards <metgerards@student.han.nl>]

Hollis Blanchard <hollis@penguinppc.org> writes:

> I'm working on supporting more than one partition map per
> architecture. Currently, x86 builds use disk/i386/pc/partition.c, and
> PPC builds use disk/powerpc/ieee1275/partition.c. Both provide
> identically-named functions for architecture-neutral code
> (e.g. grub_partition_iterate). Additionally, Apple partition code
> deals with things it shouldn't (e.g. dos_type), so we can see that
> some abstraction is needed here.

Thanks for working on this.  I planned to do this, but as you might
have noticed I did not have much time for working on GRUB 2 lately.
At the moment I do not have time to read your entire email and comment
on that, I will do that this evening.

Please make sure that for every partition type the endian is converted
to the host endian.

> In order to support both partition types (and potentially more, should
> the need arise) in the same binary, I'm introducing a "partition_ops"
> structure to struct grub_disk, which contains a couple function
> pointers that are set as appropriate at grub_disk_open time. There is
> one ops structure per partition map type (i.e. DOS and Apple right
> now).

Does this mean it will be possible to create modules for partitions?
For example applepartmap.mod or so.  This is really important to me.

> It's not all ready for submission yet, but the struct division could
> go in first, to try to commit smaller incremental patches rather than
> one massive one. Is this ok?

Both ways are fine to me.

Thanks,
Marco