Re: [multiboot] command-line format

[Robert Millan]

On Sun, Jan 17, 2010 at 07:02:16PM +0100, Grégoire Sutre wrote:
> 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?).

I really don't think this is something that should be *mandated* by the spec,
specially not for legacy compatibility reasons.

Also, how is a bootloader supposed to know about a notation specific to the
booted kernel?  GRUB doesn't have the slightest clue how kernels name their
devices, and it shouldn't; OTOH the environment who generated grub.cfg knows
all the details.

But we could add a note saying that even if it's not required, the behaviour
of using first parameter this way is widespread.

> 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.

I'm sorry, but I don't think this kind of UI complexity benefits users.

Also, I firmly believe that we shouldn't be satisfied with flawed solutions
just because they're part of our legacy baggage.  We can do better than this
because Free Software is more flexible and more powerful.  For example, NetBSD
can distribute its own version of GRUB and patch it, and coordinate an
interface change between GRUB and its kernel, etc.

We're not like BIOS vendors + Microsoft which are stuck with 40-year-old
crappy interfaces because neither of them has the flexibility to change each
others' implementation.  It would almost be funny if it wasn't because they
managed to put their i8086-encumbered legacy in every modern machine around
the world.

-- 
Robert Millan

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