[Top][All Lists]

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

Re: [PATCH] nested partitions

From: Seth Goldberg
Subject: Re: [PATCH] nested partitions
Date: Fri, 22 Jan 2010 10:43:09 -0800 (PST)
User-agent: Alpine 2.00 (GSO 1167 2008-08-23)


Quoting Robert Millan, who wrote the following on Fri, 22 Jan 2010:

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

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.

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.

The UEFI specification specifies support for nested MSDOS labels (MSDOS labels that include partitions in which another MSDOS partition table can be nested). This is not talking just about extended partitions, but about the ability to arbitrarily nest MSDOS partition tables. I can't point you to a specific implementation that uses that functionality, but the fact that it's specified should be enough to allow us to be flexible here. Why limit the nesting if architecturally it's not a problem to support (as Vladimir's existing implementation already supports arbitrary nesting).

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.

  Not only popular, but essential in the Solaris case, at least.

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

We're headed toward GPT, but we MUST continue to support the existing VTOC (that's what Solaris labels are called) scheme.


reply via email to

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