NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/55958: pciback.hide parsing error

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

From: Aleksey Arens <>
To: Manuel Bouyer <>
Subject: Re: kern/55958: pciback.hide parsing error
Date: Wed, 27 Jan 2021 00:10:55 -0800

  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.
 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.

Home | Main Index | Thread Index | Old Index