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

[phcoder <phcoder@gmail.com>]

Bean wrote:
> 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.
> 
The problem with such a design is that the partition code would always 
have to add parent partition offset to the start of subpartitions. It's 
something that I would like to hide from partition code mainly because 
people don't usually care if their code works well in nested partition 
environments and its cleaner if partition code doesn't need to not 
whether it divides a disk or subdivides a partition. In my proposition 
at each step I call a function which naturally resolves the current 
level of indirection. E.g. if we have sun partition in fdisk partition 
on biosdisk I call:
1) device->partition->probe it gives the offset
2) device->parent->partition->probe it gives the second offset
3) device->parent->parent->dev->read
As you see at every step I just resolve a level of indirection
> 
> This flag could be useful sometimes. For example, in raid devices, the
> first disk may contain partition table, but we shouldn't use it.
> 
I'm not familiar with raid but could it be that boot partition is at the 
first disk of raid just after the partition map. Then to read it we 
don't need raid modules. I don't see why such a usage case should be 
specifically excluded
And don't raid disk contain a volume header? If they do how can they 
contain the partition table in the usual place
Also existence of (hd0,1) doesn't prevent you from accessing (hd0)

-- 

Regards
Vladimir 'phcoder' Serbinenko