Re: [Design] nested partitions: Unify grub_partition and grub_disk

[Bean]

Hi,

>Hello. I was looking into nested partitions issue and propose to unify 
>grub_partition and grub_disk. In this case when a code calls grub_disk_read 
>with a >grub_disk_t which represents a partition it will correct the offset 
>and call grub_disk_read with underlying partition or disk. In this way not 
>only nested partitions >become natural but also conceptually similar fields of 
>total_sectors and len become unified. As it's an important design change I 
>send this e-mail before coding it

Actually, this is already how it works. grub_disk has a partition
pointer, which indicate if it is partition or disk, and
grub_disk_adjust_range adjust the offset for partition.

My suggestion is, always treats grub_disk as a partition, and use the
offset. For the root partition, offset is 0 so we get the whole disk.

On Sun, Mar 8, 2009 at 12:03 AM, phcoder <address@hidden> wrote:
> I forgot to speak about another question: partition naming. I see 2
> possibilities
> 1) purely numeric unified naming scheme. It means that
> (hd0,1,a) becomes (hd0,1,1)
> On one hand mixed number-letter scheme is similar to what freebsd uses but
> on the other hand numerical scheme is versatile and allows unlimited
> nestedness. And I don't see why we would use a scheme specific to one of
> many supported OSes.
> 2) Every partition map is allowed to pick the name that it likes as long as
> it contains no comma. In this way we would need to keep partition-name
> parsing functions in partitition map modules. It means that this code would
> be duplicated. But this scheme is better in the cases when partition map has
> no numbering scheme but instead has labels attached to partitions. But in
> this case IMO search command should be used find the partition
>
> I personally would prefer the first way

I'm fine with names like (hd0,1,1).

>>
>> Also an interesting question is how would "has_partitions" field be
>> handled in this scheme.
>
> Just ignored. It's actually used only to optimise some code out based on the
> assumption that some media has no partitions. Performance gain is negligible
> but if this assumption doesn't hold true grub won't be able to access the
> partitions which are really here. Famous example is a cdrom. Most people
> would assume that cdrom has no partitions. But on powerpc bootable cdroms
> use APM

This flag could be useful sometimes. For example, in raid devices, the
first disk may contain partition table, but we shouldn't use it.

-- 
Bean