All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Grégoire Sutre" <gregoire.sutre@gmail.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [multiboot] command-line format
Date: Sun, 17 Jan 2010 19:02:16 +0100	[thread overview]
Message-ID: <4B5350A8.5040108@gmail.com> (raw)
In-Reply-To: <20100115161507.GA22087@thorin>

Hi Robert,

Thanks for your detailed explanation, it was really helpful to me.  I 
understand that for compatibility with some platforms, GRUB must provide 
a way to specify two potentially different file parameters:

(a) the GRUB path to the booted file; this path does not appear in the 
multiboot command-line.
(b) the path that shall be passed to the booted file; this path (if any) 
is the first argument in the multiboot command-line.

However, my first post in this thread was more about the multiboot 
specification itself.  In light of your explanations, I would re-phrase 
my suggestion as follows: in the multiboot specification, require that 
the first argument of the MB command-line be a path to the booted file 
*in a notation that is specific to the booted kernel*.  Or, if this is 
too constraining or too confusing, simply ask that the first argument is 
an informative string that does not contain kernel options (i.e. it can 
safely be skipped).  This way, the specification would be closer to the 
reference implementation (GRUB Legacy), and, more importantly, to what 
multiboot-compliant kernels already *assume* about the format of the 
command-line (NetBSD, OpenSolaris, Xen, others?).


For GRUB 2, this could be implemented by a multiboot command that, by 
default, behaves as GRUB Legacy, but also offers a way to modify the 
implicit first argument of the multiboot command-line.  Something like:

multiboot $path[;$ospath] ...

(a) $path is the GRUB path to the booted file.
(b) $ospath is the path that shall be passed to the booted file.

By default, if there is no ';' in the first argument, $ospath is set to 
the value that GRUB Legacy would have used.  Maybe a GRUB shell variable 
`multiboot_ospath' would be better than this ';' marker.

This way, we keep the extra flexibility of having different paths, but 
we also:

- keep backward compatibility with GRUB Legacy: kernels can still assume 
that the first argument of the multiboot command-line is not a kernel 
option.
- don't force users to repeat the path for kernels that are happy with 
the way GRUB Legacy worked (all of them except OpenSolaris?).  I agree 
that this point is of no concern to most users, but in some cases 
grub-mkconfig does not work (e.g. grub-mkconfig does not support 
--root-directory at the moment), and some users prefer the flexibility 
of the command line anyway.

Grégoire




  reply	other threads:[~2010-01-17 18:02 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
2010-01-17 18:02   ` Grégoire Sutre [this message]
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=4B5350A8.5040108@gmail.com \
    --to=gregoire.sutre@gmail.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.