Re: kern/55958: pciback.hide parsing error

[Aleksey Arens <aza.sea.agenda%gmail.com@localhost>]

>  Yes. But the Xen kernel probably needs to copy it at some point (even if
>  it doens't know what it's copying). I'm not sure if it can copy something
>  arbitrary long (it may be limited e.g. to a page size).
>

As I understand it, Xen reads the cmdline string from an offset in the
module image passed-in to it.  Cf.
https://fossies.org/linux/xen/xen/arch/x86/setup.c#l_760

>  But there's something strange here: Xen is supposed to use multiboot, not
>  the NetBSD native boot protocol. In multiboot, the structures from
>  bootinfo.h are not supposed to be used.
>

Correct.  However, those arguments are not the ones being passed to
Xen, but to the module image that is being loaded by Xen.

>  So I guess that the problem is more that /boot abuses bi_modulelist_entry
>  for internal structures in the multiboot case. The problem can probably
>  be fixed in /boot without changing bootinfo.h at all.

In principle, yes.  However, in that case, a different Xen-specific
format will need to be defined.  Maybe a copy of bi_modulelist_entry
should be made, mentioning xen in its name?  This is a piece of
bootinfo that is Xen-specific, and currently, it appears that the same
structure has merely been reused to cover both cases.

At any rate, an ability to use longer —  and ideally variable-length —
strings for /netbsd's boot arguments won't hurt in the long run,
though *that* specific topic (i.e. re: /netbsd's arguments) could
become a matter for another ticket.  Right now, setting up a special
case for Xen (with fixed buffer length of e.g. 512, being a half of
Xen's limit of 1024 for the whole command line) might as well be more
than sufficient.