From: Robert Millan <rmh@aybabtu.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [multiboot] command-line format
Date: Fri, 15 Jan 2010 17:15:07 +0100 [thread overview]
Message-ID: <20100115161507.GA22087@thorin> (raw)
In-Reply-To: <4B4F4C05.8070003@gmail.com>
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
next prev parent reply other threads:[~2010-01-15 16:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-14 16:53 [multiboot] command-line format Grégoire Sutre
2010-01-14 19:07 ` Seth Goldberg
2010-01-14 23:24 ` Grégoire Sutre
2010-01-14 23:41 ` Seth Goldberg
2010-01-15 0:42 ` Grégoire Sutre
2010-01-15 16:15 ` Robert Millan [this message]
2010-01-17 18:02 ` Grégoire Sutre
2010-01-17 18:22 ` Robert Millan
2010-01-17 19:39 ` richardvoigt
2010-01-19 23:47 ` Robert Millan
2010-01-20 17:19 ` Grégoire Sutre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100115161507.GA22087@thorin \
--to=rmh@aybabtu.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.