[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Don't pass filename in multiboot command line

From: Seth Goldberg
Subject: Re: [RFC] Don't pass filename in multiboot command line
Date: Wed, 26 Aug 2009 18:58:35 -0700 (PDT)
User-agent: Alpine 2.00 (GSO 1167 2008-08-23)

Hi there,

Sorry for the delay, but I just discovered this broke booting of Solaris, and here's why: Solaris depends on knowing the name of the kernel file booted so it can locate the file within the boot archive (so that the kernel runtime linker can perform its relocations). Is there any "in-spec" way we can pass the name of the file loaded (note that this is a problem for backward compatibility (with respect to older Solaris kernels that depend on this functionality).


Quoting Vladimir 'phcoder' Serbinenko, who wrote the following on Fri, 14...:

On Mon, Aug 3, 2009 at 12:41 AM, Robert Millan<address@hidden> wrote:
On Sun, Aug 02, 2009 at 11:42:43PM +0200, Vladimir 'phcoder' Serbinenko wrote:
No. Now we have an extra element that is always present and we want to
remove but when we remove command line can be empty and code must
handle it correctly.

Please try this patch.
I haven't tried it because I know it will fail if someone does
multiboot /payload
Then cmdline_argc = 0;
At the end of the loop p=cmdline;
and *(--p) = 0 will overwrite an unrelated byte and cmdline pointer
will be the same as boot_loader_name pointer and payload will recieve
"GRUB 1.96" as command line

You're right.  I overlooked that the *(--p) change has a different purpose and
is still needed, but that's no reason we need off-by-one loops when parsing
argv.  Simply discard the first member by using a separate variable like
in my patch;  this results in more readable code.

Committed with improvements as ACK'ed by Robert on IRC
Robert Millan

 The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
 how) you may access your data; but nobody's threatening your freedom: we
 still allow you to remove your data and not access it at all."

Grub-devel mailing list

Vladimir 'phcoder' Serbinenko

Personal git repository:

Grub-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]