Re: kern/55958: pciback.hide parsing error

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

 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.