[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netbsd-bugs
Subject:    Re: kern/55958: pciback.hide parsing error
From:       Aleksey Arens <aza.sea.agenda () gmail ! com>
Date:       2021-01-29 11:05:01
Message-ID: 20210129110501.DBB081A923B () mollari ! NetBSD ! org
[Download RAW message or body]

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

From: Aleksey Arens <aza.sea.agenda@gmail.com>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: jnemeth@cue.bc.ca, kern-bug-people@netbsd.org, gnats-admin@netbsd.org, 
	netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
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
 >
 
 Ok.
 
 > 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
 doing.
 
 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?
 

[prev in list] [next in list] [prev in thread] [next in thread]