All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Millan <rmh@aybabtu.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Cc: "Yoshinori K. Okuji" <okuji@enbug.org>
Subject: Re: [Design] nested partitions: Unify grub_partition and grub_disk
Date: Mon, 13 Apr 2009 16:00:37 +0200	[thread overview]
Message-ID: <20090413140037.GD12170@thorin> (raw)
In-Reply-To: <49E1126D.4050604@gmail.com>

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



  reply	other threads:[~2009-04-13 14:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-07 14:58 [Design] nested partitions: Unify grub_partition and grub_disk phcoder
2009-03-07 15:38 ` Robert Millan
2009-03-07 16:03   ` phcoder
2009-03-07 18:05     ` Bean
2009-03-07 18:46       ` phcoder
2009-04-11 21:58     ` phcoder
2009-04-13 14:00       ` Robert Millan [this message]
2009-04-14 15:15         ` Yoshinori K. Okuji

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090413140037.GD12170@thorin \
    --to=rmh@aybabtu.com \
    --cc=grub-devel@gnu.org \
    --cc=okuji@enbug.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.