Re: kern/55958: pciback.hide parsing error

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Jan 28, 22:33, Aleksey Arens wrote:
}
} >      I'm pretty sure that somebody previously mentioned that Xen
} > requires multiboot.  I've haven't read your entire message, but
} > unfortunately it appears that you have spent a lot of time on this
} > for naught.  Our native bootloader can do multiboot and has been
} > able to boot Xen for many years.  You should have a look here:
} > http://wiki.netbsd.org/ports/xen/ and here:
} > http://wiki.netbsd.org/ports/xen/howto/ .  This is from my development
} > box:
} >
} > menu=Boot Xen with 6GB for dom0:load /netbsd.xen0 console=pc;multiboot /xen45-kernel/xen.gz dom0_mem=6GB dom0_max_vcpus=1 dom0_vcpus_pin
} 
} Thank you for joining the discussion.  One of the essential points in
} my previous message is that I suspect that there is at least a bug in
} the multiboot implementation in /boot.  I'm also concerned about the
} fact that the same data-structures are reused in implementing the
} binary module layout for the cases when a native module is loaded and
} when a multiboot module is loaded.  I hope that these points would
} become clear to you if you invest your time and give your full
} attention to the entire message.
} 
} Finally, the command passed to the module -- in the example that you
} had displayed -- is a bit too short.  To see the issue at hand, you'd
} need to make it over 80 characters long, and then observe that it does
} get truncated once it makes it to Xen.  This was demonstrated in the
} first three messages to this PR.
} 
} > The "load" part is what does module loading (in this case, the
} > NetBSD kernel which is built as a Xen module) and the "multiboot"
} > part is what boots the Xen kernel.  Note that since it is my
} > development box, I have many different variants of this line.
} 
} Could we please go into more details thereby?  The Xen expects the
} modules to be loaded according to multiboot protocol.  What I'm seeing
} is that "load" uses the same BM_TYPE_KMOD for either the case of
} native or multiboot module loading scenario.  Furthermore:
}   https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/exec.c#exec_multiboot
}   https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/exec.c#exec_netbsd
} are both calling to the same
}   https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/exec.c#module_init
} function, in which the short buffer is copied:
}   https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/exec.c#763
} 
} So, clearly, both native and multiboot modules are initialized in an
} identical fashion.  This must have led to this bug.  I request that
} this bug be fixed, and I propose that it be done by separating the
} code responsible for module loading in case of multiboot and Xen.

     Keep in mind that the NetBSD kernel itself is the module.
You're not loading a module into the NetBSD kernel, you're loading
a module into the Xen kernel (Xen is the host OS).  The arguments
are for the kernel itself, not a module, so you need to find where
the kernel parses its own command line.  This has nothing to do
with NetBSD modules.

}-- End of excerpt from Aleksey Arens