Re: kern/55958: pciback.hide parsing error

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

A subsequent discussion at #xendevel ensued.  It was learned that as a
matter of fact, Xen does expect multiboot protocol for module loading.
Also, a reference to a respective implementation in FreeBSD was
suggested:
  https://cgit.freebsd.org/src/tree/stand/i386/libi386/multiboot.c#n253

Thus, it would be fair to say that sharing data-structures between the
native module loader and code that is involved in loading Xen modules
-- which must be done not with a native bootloader, but with a
multiboot loader -- is not desirable.  (I must clarify thereby.  I'm
talking about the data structures that implement layout of loaded
module images, not the module chain descriptions; the latter could be
left intact.)

Since conceptually multiboot and native module loading are different
module loading schemes, I would like to suggest that a multiboot
protocol be implemented separately, with a separate set of
data-structures.  If this approach is taken, then there shall be no
binary compatibility issue whatsoever with native loading, and
whatever binary compatibility might be occurring with the /netbsd's
multiboot loading case (which is AFAIK is not enabled by default in
the kernel config anyway) should be treated as kernel bugs, since a
standard-conforming multiboot kernel should always be loadable by a
standard-conforming multiboot bootloader (apart perhaps from the
initial ramdisk related caveat noted below).

I am interested in implementing the multiboot functionality -- at
least version 1, but there is also an interest on my part in
implementing version 2 -- for /boot, and accommodating Xen-specific
workarounds from FreeBSD.  The latter workarounds are related to
initial ramdisk implementation differences and multiboot protocol
requirements.

I suppose we could look into the ramdisk issues, and decide whether
the multiboot implementation must be strict, or if it can be relaxed,
and if Xen's code could be adjusted.  I favor the former option -- of
implementing the standard strictly in the bootloader.  This option may
lead to a need to adjust /netbsd a bit w.r.t. the initrd issues with
multiboot.  However, the result would be a kernel that fully conforms
to multiboot standard.  Also, since MULTIBOOT is non-default for
/netbsd, the impact would be low.