Re: [multiboot] command-line format

[Robert Millan]

On Thu, Jan 14, 2010 at 05:53:25PM +0100, Grégoire Sutre wrote:
>
> As mentioned in a previous thread, I had some problems getting multiboot  
> options recognized by the NetBSD kernel, and this was actually due to  
> the fact that GRUB Legacy implicitly passes the booted file as first  
> argument whereas GRUB 2 doesn't [1].
>
> I started a thread on NetBSD's port-i386 mailing list [2] on the format  
> of the multiboot command-line, and the discussion moved towards the  
> change in GRUB regarding the first argument (booted kernel in GRUB  
> Legacy, removed in GRUB 2).  I ended up doing tests with Xen, which is  
> also multiboot-compliant, and Xen also skips the first argument in its  
> command-line parsing code (well, it's a bit more complex, see [3] for  
> details if you're interested).
>
> In the end, it may be the case that most multiboot-compliant kernels out  
> there still assume that the first argument is the booted file name, and  
> skip it without even looking at it.  Do you know of any kernel that does  
> not make this assumption?

Hi Grégoire,

This might sound contradictory to you, but we did this change precisely with
those kernels in mind.  We didn't do this just because we're pedantic when
reading the spec!  Our goal was to improve support for these situations.  I
will explain this:

GRUB Legacy used to pass this information implicitly as you point out.  As a
result, most of these kernels just skip the first parameter, but there are
also a few (like the kernel of OpenSolaris) which make use of the information
in it (to find some other files I think).

The problem we found is that because the file path parameter was implicit,
user was unable to modify it.  As a result, it became impossible to e.g.
load kernel of OpenSolaris from one device/path and its associated files
from somewhere else.  We wanted to provide the best user experience on
those platforms (Multiboot is our primary target, it's the boot protocol of
the GNU system and is much more important for GRUB than Linux loaders),
and this limitation was deemed unacceptable.

With this change, we provided more flexibility.  If users want to retain
the old protocol, they can still do this.  For example if a kernel just
ignores first parameter:

  multiboot /kernel unused foo bar

Or if it really wants to know the pathname:

  multiboot /kernel /kernel foo bar

One might think that this is an unnecessary burden, but the fact is that
users generally don't need to type any of this by hand (or even edit grub.cfg
by hand).  We provide the grub-mkconfig utility which is extensible and can
support this for a variety of different kernels.  So when someone writes a
script snippet for kernel of NetBSD or kernel of OpenSolaris (e.g.
10_knetbsd.in and 10_kopensolaris.in), they can make GRUB add a dummy
parameter for the kernel to skip (NetBSD's) or a file path for the kernel
to rely on (OpenSolaris').

P.S: please forward this message to the relevant NetBSD mailing list(s) if
you think this is appropiate.  TIA

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi