partition map reorganization

partition map reorganization

[Hollis Blanchard]

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.

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

struct grub_partition_ops {
	grub_err_t (*iterate) (struct grub_disk *disk,
					int (*hook) (const grub_partition_t partition));
	grub_partition_t (*probe) (struct grub_disk *disk, const char *str);
	char * (*get_name) (const grub_partition_t p);
};

Impact to existing code can be minimized with wrappers like this:

static inline char *
grub_partition_get_name (const grub_partition_t p)
{
	return p->disk->ops->get_name (p);
}

Everything is going ok, but as the first step I'd like to make sure 
this idea is acceptable. Neutral code only uses a couple fields of 
struct grub_partition, so I would like to break the current struct 
grub_partition in two: a generic partition (i.e. what describes a disk 
partition in general) and a DOS-specific partition:

struct grub_partition {
	unsigned long start;
	unsigned long len;
	unsigned int index;
	struct grub_disk_t disk;
};

struct grub_dos_part {
	struct grub_partition generic;
	unsigned long offset;
	unsigned long ext_offset;
	int dos_part;
	int bsd_part;
	int dos_type;
	int bsd_type;
}

The generic grub_partition needs to be embedded in grub_dos_part so 
that neutral code can use a grub_partition pointer and then the 
map-specific code (e.g. grub_partition_get_name) can convert back to 
the grub_dos_part pointer.

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?

-Hollis

Re: partition map reorganization

[Tomas Ebenlendr]

I have just two questions. (I didn't see the code for a long time, so
I'm sory if I misunderstand something.)

> struct grub_partition_ops {
> 	grub_err_t (*iterate) (struct grub_disk *disk,
> 					int (*hook) (const grub_partition_t 
> 					partition));
> 	grub_partition_t (*probe) (struct grub_disk *disk, const char *str);
> 	char * (*get_name) (const grub_partition_t p);
> };
> 
> Impact to existing code can be minimized with wrappers like this:
> 
> static inline char *
> grub_partition_get_name (const grub_partition_t p)
> {
> 	return p->disk->ops->get_name (p);
> }

Do you want partition ops to be member of disk structure?

> struct grub_partition {
> 	unsigned long start;
> 	unsigned long len;
> 	unsigned int index;
> 	struct grub_disk_t disk;
> };

Umm, what about 'type' field? (To be sure that some generic partition is
the dos one.)


-- 
                                 Tomas 'ebi' Ebenlendr
                                 http://get.to/ebik
                                 PF 2004.83695513307

Re: partition map reorganization

[Marco Gerards]

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

Re: partition map reorganization

[Hollis Blanchard]

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

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

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

Re: partition map reorganization

[Hollis Blanchard]

On Nov 2, 2004, at 12:56 AM, Tomas Ebenlendr wrote:
>
> I have just two questions. (I didn't see the code for a long time, so
> I'm sory if I misunderstand something.)
>
>> struct grub_partition_ops {
>> 	grub_err_t (*iterate) (struct grub_disk *disk,
>> 					int (*hook) (const grub_partition_t
>> 					partition));
>> 	grub_partition_t (*probe) (struct grub_disk *disk, const char *str);
>> 	char * (*get_name) (const grub_partition_t p);
>> };
>>
>> Impact to existing code can be minimized with wrappers like this:
>>
>> static inline char *
>> grub_partition_get_name (const grub_partition_t p)
>> {
>> 	return p->disk->ops->get_name (p);
>> }
>
> Do you want partition ops to be member of disk structure?

Yes. A disk has a particular partition map format.

>> struct grub_partition {
>> 	unsigned long start;
>> 	unsigned long len;
>> 	unsigned int index;
>> 	struct grub_disk_t disk;
>> };
>
> Umm, what about 'type' field? (To be sure that some generic partition 
> is
> the dos one.)

I don't understand what you mean, can you provide an example of how it 
would be used by arch-neutral code? If you're thinking of something 
like this:
	switch (p->type) {
		case DOS_PARTITION:
			name = dos_get_name(p);
			break;
		case APPLE_PARTITION:
			name = apple_get_name(p);
			break;
	}
... then that is much better handled by calling through the disk->ops 
function pointers:
	name = grub_partition_get_name(p);

Also consider that an Apple partition map entry has a 32-character 
"type" field. How would you represent that as an integer (which I think 
is what you're requesting)?

-Hollis

Re: partition map reorganization

[Marco Gerards]

Hollis Blanchard <hollis@penguinppc.org> writes:

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

IMHO it is part of the job.  I think most code was written to be
portable, but I think it has not been tested.  If it all works, just
ignore what I said here.

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

First of all it is about modularity.  On the PC the user can configure
the core module to support ext2fs, for example.  In that case normal
mode can be loaded from disk.  After that it can also load other
filesystems, for example to load the kernel from a jfs partition or
so.

What I want in the future is that it is not only possible to have a
disk driver and filesystem in a module, but partition map support as
well.

On the PC port nothing will change, you just have to add support for
PC style partitions to the core module.  There is not a chicken-egg
problem here (from what you are saying, it sounds like you expect
one), the main issue is modularity.

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

Please implement it because it is really important in the future.  It
is also how everything else in GRUB 2 works.  So basically you need to
be able to load and register partition map modules, just like you can
load a disk driver (as they are in disk/) and filesystem modules (like
in filesystem/).

Until we have module support on the PPC, all partition modules should
be activated by default for grubof.  It is important that the
partition type can be detected somehow, perhaps some partition schemes
can live side by side, etc.  At the moment only PC and apple
partitions are supported.  In the future I plan to add amiga style
partitions.

Thanks,
Marco

Re: partition map reorganization

[Tomas Ebenlendr]

> I don't understand what you mean, can you provide an example of how it 
> would be used by arch-neutral code? If you're thinking of something 
> like this:
> 	switch (p->type) {
> 		case DOS_PARTITION:
> 			name = dos_get_name(p);
> 			break;
> 		case APPLE_PARTITION:
> 			name = apple_get_name(p);
> 			break;
> 	}
> ... then that is much better handled by calling through the disk->ops 
> function pointers:
> 	name = grub_partition_get_name(p);

Ok. This was not clear to me. I saw no connection between ops and
struct. So, struct type must be "given" together with ops.

-- 
                                 Tomas 'ebi' Ebenlendr
                                 http://get.to/ebik
                                 PF 2004.8382375468

Re: partition map reorganization

[Marco Gerards]

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.

After a long time of not being active, I finally found some time again
to work on GRUB.  Just to keep you all up-to-date, I am going to work
on this multiple partition map feature and I have talked with Hollis
about it.

What I am planning to do is at first make the partition system work
more or less like the filesystem modules.  So the type of partition
map can be probed and the user can configure which kind of partition
maps will be supported (using modules).

My current goal is getting GRUB 2 to work on the PegasosII.  The
pegasos has RDB (amiga style) partition maps.  The BriQ (a machine
Hollis has) has PC style partition maps.  So all 3 partition map types
should be supported by GRUB 2.  This will make further ports easier as
well.

So basically, I will check in some patches next days to make GRUB 2
work smoothly on the PegasosII.  After that I will send in a patch to
support multiple partition maps.  When that is in I will send in a
patch to add RDB support (which is finished already).

After that I will work a bit more on the PPC port, especially on
PegasosII specific things.  The VGA/VESA stuff I planned to do has to
wait because my test/development PC is still broken. :/

This is my priority list for the moment (in order in which I will work
on this):

- Fixing bugs in the PPC port.
- Modular partition maps.
- Implement RDB support.
- Implement Amiga FFS support.
- Write longjmp, etc for the PPC.
- Implement the relocator for the PPC (I need module support in
  grub-emu to make this easy for me to implement).
- A chainloader.
- Have another look at the terminal.

This will keep me busy for quite a while, perhaps I will do some
filesystem and PC work in the meanwhile.  If someone wants to help
with the PPC port, you can work on implementing longjmp and the
relocator.  The first requires knowledge about assembler and the
second is what I described above.

Hopefully it is clear what I am going to do and I hope people are
willing to help me with the assembler stuff and the relocator. :)

Thanks,
Marco

Re: ppc setjmp/longjmp

[Hollis Blanchard]

On Nov 13, 2004, at 6:47 AM, Marco Gerards wrote:
> This will keep me busy for quite a while, perhaps I will do some
> filesystem and PC work in the meanwhile.  If someone wants to help
> with the PPC port, you can work on implementing longjmp and the
> relocator.  The first requires knowledge about assembler and the
> second is what I described above.

setjmp/longjmp don't sound too bad. I guess setjmp just needs to save 
the register state into memory and longjmp restores it?

-Hollis

Re: ppc setjmp/longjmp

[Yoshinori K. Okuji]

On Monday 15 November 2004 17:09, Hollis Blanchard wrote:
> setjmp/longjmp don't sound too bad. I guess setjmp just needs to save
> the register state into memory and longjmp restores it?

Yes. I'd recommend implementing this based on glibc 
(glibc/sysdeps/powerpc/{powerpc32,powerpc64}).

Okuji