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.