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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
