[Design] nested partitions: Unify grub_partition and grub_disk

[Design] nested partitions: Unify grub_partition and grub_disk

[phcoder]

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

Regards
Vladimir 'phcoder' Serbinenko

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

[Robert Millan]

On Sat, Mar 07, 2009 at 03:58:46PM +0100, phcoder wrote:
> 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

Makes sense to me.  But it'd be interesting to hear from the person who
designed it this way.  Perhaps there's a non-obvious reason.

Who's that?  Maybe Marco or Okuji?

Also an interesting question is how would "has_partitions" field be
handled in this scheme.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

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

[phcoder]

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



-- 

Regards
Vladimir 'phcoder' Serbinenko

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 <phcoder@gmail.com> 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

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

[phcoder]

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

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

[phcoder]

Ping. Is it ok for me to implement it this way?
phcoder 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
>> 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
> 
> 
> 


-- 

Regards
Vladimir 'phcoder' Serbinenko

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

[Robert Millan]

On Sat, Apr 11, 2009 at 11:58:05PM +0200, phcoder wrote:
> Ping. Is it ok for me to implement it this way?

I'd really like it if Okuji could give his impression on this one, if
possible.

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

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

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

[Yoshinori K. Okuji]

On Monday 13 April 2009 23:00:37 Robert Millan wrote:
> On Sat, Apr 11, 2009 at 11:58:05PM +0200, phcoder wrote:
> > Ping. Is it ok for me to implement it this way?
>
> I'd really like it if Okuji could give his impression on this one, if
> possible.

I don't think I am the right one to ask, because I myself don't use any BSD 
variant any longer. So, in short, I don't care for myself.

As partition specifications are relevant to the user, it is better to ask the 
user.

(At least when I used GNU/Hurd with BSD disk slices, I preferred a, b, c to 1, 
2, 3. Something called "least surprising".)

Regards,
Okuji

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