grub-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] nested partitions


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: [PATCH] nested partitions
Date: Fri, 22 Jan 2010 19:03:21 +0100
User-agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109)

Robert Millan wrote:
> I haven't checked the specific details, but I think this approach is fine IF
> we only recurse for partition types where this makes sense.  This includes:
>
>   - BSD partition types inside MSDOS labels
>   - Solaris partition type inside MSDOS labels
>   
What with minix?
> This can be done by extending "has_partitions" to be set to "yes" in those
> specific partition types.  The implementation should be the least intrusive
> possible, taking into account that this kind of situations are an oddity
> rather than the norm.
>
>   
Partition types are easily screwed. Why not just check for the presence
of the label?
> As for the other situations, the more I think about this, the more convinced
> I am that this whole "partition nesting" concept is a broken mess.  I think I
> already explained why in this list, but I can rehash the reasons if anyone's
> interested.  I don't want to compromise on such part of GRUB core for the sake
> of supporting this kind of layouts.
>   
Actually I don't see my patch as of any compromise. On the contrary:
current code is a compromise with a horrible set of functions verbatimly
replicated across all partition modules.
> The only reason I'm open to implementing these two cases [1] is that they seem
> to be inmensely popular among *BSD systems and Solaris derivatives.
>
>   
Solaris nested partition table provides decent embedding region.
FreeBSD supports GPT and doesn't attempt to nest partitions on it.
> As for *BSD and Solaris who read this, my advice is to step away, ditch the
> whole MSDOS label burden and just settle on a clean label without the limits
> DOS ones have.  If you strive for compatibility, GPT is a good choice IMO (and
> the rest of the free world seems to be moving in this direction thanks to 2 
> TiB
> limit).
>
> [1] I know the first one is already implemented, but your approach makes it
>     less ad-hoc and splits code off part_msdos.mod, which is an improvement.
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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