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
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel