Re: [RFT] nested partition issues

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3446 bytes --]

On 11/02/2010 04:58 PM, Grégoire Sutre wrote:
> Hi,
>
> The main issue at hand is that, to support NetBSD, we need a working
> grub-setup for the (very common) case where the NetBSD disklabel is
> placed
> in an MSDOS partition.
>
> If we need to add yet other ``strcmp (..._partmap->name, ...)'' tests to
> grub-setup, then we likely have bad abstractions.
>
Usually I would have agreed with you. Unfortunately on-disk layout isn't
something that is well structured. There is a bunch of special cases,
exceptions and plain brain damage that the code to handle all
possibilities will necessarily be more complicated than it should. And I
feel like the abstractions taken for NetBSD are the right one.
As for embedding code it's written specially in the following way
if (<usual config 1>)
{
...
} else if (<usual config 2>)
{
...
} else {
   error ("Something unusual, better fail than damage anything");
}
If you test the netbsd case and it works as it should you can add the
strcmp (..._partmap->name, ...) part.
>
>> Actually now we follow the actual nesting of partitions. Even though
>> net-/openbsd label metadate is placed inside a partition it still
>> describes the whole disk as is manifested by it having entries for
>> partitions not contained inside the partition containing label metadata.
>> E.g.
>> (hd0,netbsd6) may be physically contained within (hd0,msdos3) but still
>> be described inside the label present in second sector (hd0,msdos2).
>> Place of metadata is secondary to deciding what the nesting of
>> partitions is. Primary criteria is what this metadata describes.
>
> So, basically, as soon as a disklabel uses absolute offsets, this
> disklabel
> must be viewed as a top-level disklabel?
No. Even using absolute offsets the label can be limited to current
partition. It's the case of minix and FreeBSD. Main criteria is
"If there can be only one label of this type per disk and it may
describe (sub)partitions outside its own partition, then it's top-level"
>
> I'm afraid that this will make things more complicated than they should
> be.  But that's just me.
>
>
>> This is, of course, very unfortunate design but since we support NetBSD
>> we need such hacks. It's better than being faced with the problems of
>> kind "My XYZOS handles my partition scheme perfectly but GRUB doesn't
>> see half of partitions."
>
> I did not see reports of such problems (for NetBSD partitions) since I
> merged the code to ``external'' partitions [1].  Could you please
> point me
> to such reports?
>
This was based on the image you sent me once.
> In the previous implementation, if partition e: in a NetBSD disklabel is
> discarded, it's because e: describes an ``external'' partition.  This
> external partition is (in all useful cases) described in another
> partition
> map, where it is properly nested, hence it will be found by GRUB.
>
Hm, it doesn't seem to be what you told me previously. AFAIR you told me
that disklabel only handles first label found, and now you say that the
same information is duplicated in every NetBSD partition.
> Grégoire
>
> [1] http://lists.gnu.org/archive/html/grub-devel/2010-07/msg00109.html
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>


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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]