Re: kern/55958: pciback.hide parsing error

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

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

From: Aleksey Arens <aza.sea.agenda%gmail.com@localhost>
To: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
	gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/55958: pciback.hide parsing error
Date: Wed, 27 Jan 2021 22:09:04 -0800

 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.