[Top][All Lists]

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

Re: partition map reorganization

From: Marco Gerards
Subject: Re: partition map reorganization
Date: Tue, 02 Nov 2004 09:25:28 +0000
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

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.

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.


reply via email to

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