[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: partition map reorganization

From: Hollis Blanchard
Subject: Re: partition map reorganization
Date: Tue, 2 Nov 2004 09:01:23 -0600

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]