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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
