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

[Seth Goldberg]

Hi,

  Any chance of having a 'multiboot1' module that can continue to pass the 
multiboot filename as arg0 ?

 --S

Quoting Seth Goldberg, who wrote the following on Wed, 26 Aug 2009:

> 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).
>
> Thanks,
> --S
>
> 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
> > > address@hidden
> > > http://lists.gnu.org/mailman/listinfo/grub-devel
> >
> >
> >
> > --
> > Regards
> > Vladimir 'phcoder' Serbinenko
> >
> > Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
> >
> >
> > _______________________________________________
> > Grub-devel mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/grub-devel