grub-devel
[Top][All Lists]
Advanced

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

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


From: phcoder
Subject: Re: [Design] nested partitions: Unify grub_partition and grub_disk
Date: Sat, 07 Mar 2009 19:46:54 +0100
User-agent: Thunderbird 2.0.0.19 (X11/20090105)

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




reply via email to

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