On Fri, May 30, 2025 at 12:02:07PM +0200, Christoph Badura wrote:
> On Thu, May 29, 2025 at 09:23:46PM +0200, Manuel Bouyer wrote:
> > On Thu, May 29, 2025 at 03:01:50PM -0400, Chuck Zmudzinski wrote:
> > > The strange part is that it is necessary to pass -c to the DOM0 in
> > > boot.cfg to
> > > actually disable com* and the bootloader does not execute the
> > > userconf=disable com*
> > > command that is present in boot.cfg when booting NetBSD/xen DOM0. The
> > > userconf=com*
> > > setting works for the boot without Xen, but with Xen the bootloader
> > > ignores that
> > > setting in boot.cfg.
> >
> > This is because the userconf command from the boot loader doens't make it
> > to the dom0 kernel.
> > Remember that when booting Xen; Xen is the kernel and XEN3_DOM0 a module.
> > I don't know if multiboot allows passing extended informations to a module.
>
> Every module can be passed a string. That's even in the 0.6.96
> specification. Took me 5 minutes to look that up.
Yes, that's what we do already for bootdev or other command line parameters.
but userconf is a structure (a list of strings actually).
For multiboot we'd need to convert it back to a single string, and
handle it on the kernel side (and make sure to no reach the string
len limit). This has not been done yet.
>
> And even if standard multiboot doesn't allow it. It is our bootloader code
> so we can extend it every way we like.
Not exactly. Xen comes in the way.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
