Re: GPT attributes in dkwedge [PATCH]

[Simon Burge <simonb%NetBSD.org@localhost>]

Martin Husemann wrote:

> On Sat, Sep 16, 2023 at 06:51:40AM -0000, Michael van Elst wrote:
>
> > There is one caveat. Since all x86 bootloader data is funneled through
> > the bootinfo structure we have:
> > 
> > struct btinfo_rootdevice {      
> >         struct btinfo_common common;
> >         char devname[16];       
> > };
> > 
> > So we have 16 chars to store the identifier (including a NAME= or
> > wedge: prefix), that's not enough for a UUID.
>
> So we should create btinfo_rootdevice2 and extend that size to
> something more reasonable nowadays or with variable length (and have
> the bootloader pass the extended structure if strings are longer).

You don't need to do anything fancy here with a new bootinfo type.
Because bi_add() uses the length as well the type when adding more data
to be passed to the kernel, a new /boot with a longer devname will work
with an older kernel without any problems (and vice versa).

The only corner case that an older kernel won't understand a longer root
device name passed in by a newer /boot as the old kernel will still have
the 16 char length limit.  As long as we don't expect the combination of
"old kernel", "new /boot" and "new long fancy rootpath" to work, we're
all good.

I tested these cases when playing around root-on-zfs, and am using a
devname length of 80.  On my current test box, the rootdev passed to
the kernel is "zfs:tank/ROOT/default".  I forget why I chose 80 as the
length - I guess I hit a case in testing where 64 wasn't enough.

Cheers,
Simon.