[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/55958: pciback.hide parsing error
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: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
Cc: jnemeth%cue.bc.ca@localhost, kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
Subject: Re: kern/55958: pciback.hide parsing error
Date: Fri, 29 Jan 2021 03:03:45 -0800
by Manuel Bouyer:
> When started as dom0 (or as domU, the code path is the same), the kernel
> command line (which is the module command line in multiboot, when started
> as dom0) is in start_info.cmd_line as is a plain text string, not a
> btinfo_modulelist or bi_modulelist_entry.
> See xen_parse_cmdline() in xen_machdep.c
> This is not exactly how it works. Yes, the load command is parsed the
> same way for both native and multiboot case, using the same structure. But
> then the exec_multiboot1() function will convert the native structure
> to multiboot format. mmo_string points to bim->path, not the bim
> structure itself.
> So to fix the problem no change to bootinfo.h is needed; only the
> boot loader needs to be changed to pass the full string to exec_multiboot1().
> For example, instead of reusing bi_modulelist to represent the module,
> module_init() could use a private structure, which is then converted
> to the appropriate interface depending on the boot mode.
Thank you for clarifying these details to me. I have not tracked the
codepath to that point, and was wondering what those functions were
Your suggestion about handling this problem does sound good to me.
I was concerned initially, if bi_modulelist_entry struct had played a
special role in further processing. I noticed the field name has been
changed from "path" to 'kmod". Does it reflect its purpose? Is there
a detailed documentation on NetBSD's boot protocol, aside from the
source code itself?
One question remains. Since now the exec.c:module_init() would
potentially fill out an intermediate struct with a long buffer, how
should the code constructing the module image for native
(non-multiboot) bootloading handle the argument buffer length? Would
doing sizeof() on the corresponding bi_modulelist_entry struct's entry
be sufficient? Perhaps, there should be a const defined in the
bootinfo.h for this purpose?
Main Index |
Thread Index |