Re: partition map reorganization

[Hollis Blanchard]

On Nov 2, 2004, at 3:25 AM, Marco Gerards wrote:

> Hollis Blanchard <address@hidden> 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.

No problem, just wanted to get it out there now so everyone would have 
time for comments.

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

I'm actually not writing any partition map code, just rearranging the 
code that's already present.

> > 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.

Why is that important?

Also, please describe how a partition map or filesystem module can be 
loaded at runtime when that partition map or filesystem would be needed 
to load anything from the disk in the first place?

I was not initially planning to support a register/unregister model for 
partition map support. But that should be easy enough as a follow-on 
patch.

-Hollis