Hi, 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 limit).
We're headed toward GPT, but we MUST continue to support the existing VTOC (that's what Solaris labels are called) scheme.
--S _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
