Re: kern/55958: pciback.hide parsing error

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

The following reply was made to PR kern/55958; it has been noted by GNATS.

From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
To: Aleksey Arens <aza.sea.agenda%gmail.com@localhost>
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
        gnats-bugs%netbsd.org@localhost
Subject: Re: kern/55958: pciback.hide parsing error
Date: Wed, 27 Jan 2021 09:25:23 +0100

 On Wed, Jan 27, 2021 at 12:07:33AM -0800, Aleksey Arens wrote:
 >  This sounds like a good approach.  Please allow me to extend it a
 > bit.  Adding another field to the module in addition to an existing
 > one is a natural instance of a scheme involving either versioning or
 > capability attributes associated with the module.  Now, versions and
 > capabilities could very well be encoded into long (just a few
 > kilobytes at most) strings.  So, we just need an ability to introduce
 > variable-size string buffers that would encode all the attributes
 > associated with a module.  The struct containing this var-size string
 > might also include a field for the encoding id (some GUID?).  After
 > all, what we're doing here is introducing a new structure to the
 > module interface that is binary-incompatible with the extant one, so
 > why not indeed make it extensible in a seamless fashion?  Furthermore,
 > all sorts of fancy module argument schemes would fall in nicely into
 > such an approach -- the only question would be the kernel's
 > willingness to parse and interpret the language within the string, but
 > there shall be no issue with binary compatibility.
 
 This is a more radical change, this would need to be discussed on port-amd64
 and port-i386 I guess.
 
 > 
 > My only concern is a question of how would a Xen kernel recognize the
 > newer format.  I could look at the boot code more closely, and
 > determine if it's something that could be done by altering the
 > bootloader itself or not.  My guess is that it doesn't, but I would
 > certainly appreciate additional insight.  If I understand it
 > correctly, the bi_modulelist_entry struct does not represent any of
 > Xen's ABI, and Xen's boot parameters are filled out from this struct
 > by the boot's code.
 
 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).
 
 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.
 
 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.
 
 -- 
 Manuel Bouyer <bouyer%antioche.eu.org@localhost>
      NetBSD: 26 ans d'experience feront toujours la difference
 --