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

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

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1377 bytes --]

According to multiboot specification "It should be possible to write
compliant boot loaders that load the OS image from a variety of
sources, including floppy disk, hard disk, and across a network. "
It implicitly says that kernel shouldn't care about filename used by
bootloader. About commandline it's only said:
"If bit 2 of the `flags' longword is set, the `cmdline' field is
valid, and contains the physical address of the command line to be
passed to the kernel. The command line is a normal C-style
zero-terminated string"
Currently grub however passes filename as first argument of command line.
Felix Zielcke did a series of tests and it revealed that OSes
subdivide into two categories:
1) Ones that don't care whether this argument is omitted altogether or
not (e.g. the don't ignore second argument even if filename is
omitted)
2) Solaris (for kernel name) and AROS (for module name) both assume
that filename is the same under grub and OS. This assumption isn't
necessarily true. These OSes are broken one way or another. If we omit
the first argument user can workaround the problem by supplying
kernel/module OS  image name as first argument of multiboot/module
command line
E.g.
multiboot /RPOOL/opensolaris/@/platform/i86pc/kernel /platform/i86pc/kernel
-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

[-- Attachment #2: mbcmd.diff --]
[-- Type: text/plain, Size: 2003 bytes --]

diff --git a/ChangeLog b/ChangeLog
index e553828..429bb75 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2009-08-01  Vladimir Serbinenko  <phcoder@gmail.com>
+
+	* loader/i386/multiboot.c (grub_multiboot): Don't pass filename to
+	payload.
+	(grub_module): Likewise.
+
 2009-07-31  Vladimir Serbinenko  <phcoder@gmail.com>
 
 	* partmap/pc.c (pc_partition_map_iterate): Check that boot flags are
diff --git a/loader/i386/multiboot.c b/loader/i386/multiboot.c
index 87ffcae..f25f77b 100644
--- a/loader/i386/multiboot.c
+++ b/loader/i386/multiboot.c
@@ -257,9 +257,12 @@ grub_multiboot (int argc, char *argv[])
   mmap_length = grub_get_multiboot_mmap_len ();
 
   /* Figure out cmdline length.  */
-  for (i = 0, cmdline_length = 0; i < argc; i++)
+  for (i = 1, cmdline_length = 0; i < argc; i++)
     cmdline_length += grub_strlen (argv[i]) + 1;
 
+  if (cmdline_length == 0)
+    cmdline_length = 1;
+
   boot_loader_name_length = sizeof(PACKAGE_STRING);
 
 #define cmdline_addr(x)		((void *) ((x) + code_size))
@@ -351,14 +354,16 @@ grub_multiboot (int argc, char *argv[])
   if (! cmdline)
     goto fail;
 
-  for (i = 0; i < argc; i++)
+  for (i = 1; i < argc; i++)
     {
       p = grub_stpcpy (p, argv[i]);
       *(p++) = ' ';
     }
 
   /* Remove the space after the last word.  */
-  *(--p) = '\0';
+  if (p != cmdline)
+    p--;
+  *p = 0;
 
   mbi->flags |= MULTIBOOT_INFO_CMDLINE;
   mbi->cmdline = (grub_uint32_t) cmdline_addr (grub_multiboot_payload_dest);
@@ -422,9 +427,12 @@ grub_module  (int argc, char *argv[])
       goto fail;
     }
 
-  for (i = 0; i < argc; i++)
+  for (i = 1; i < argc; i++)
     len += grub_strlen (argv[i]) + 1;
 
+  if (len == 0)
+    len = 1;
+
   cmdline = p = grub_malloc (len);
   if (! cmdline)
     goto fail;
@@ -436,7 +444,9 @@ grub_module  (int argc, char *argv[])
     }
 
   /* Remove the space after the last word.  */
-  *(--p) = '\0';
+  if (p != cmdline)
+    p--;
+  *p = '\0';
 
   if (mbi->flags & MULTIBOOT_INFO_MODS)
     {

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

[Robert Millan]

On Sat, Aug 01, 2009 at 03:23:04PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> According to multiboot specification "It should be possible to write
> compliant boot loaders that load the OS image from a variety of
> sources, including floppy disk, hard disk, and across a network. "
> It implicitly says that kernel shouldn't care about filename used by
> bootloader. About commandline it's only said:
> "If bit 2 of the `flags' longword is set, the `cmdline' field is
> valid, and contains the physical address of the command line to be
> passed to the kernel. The command line is a normal C-style
> zero-terminated string"
> Currently grub however passes filename as first argument of command line.
> Felix Zielcke did a series of tests and it revealed that OSes
> subdivide into two categories:
> 1) Ones that don't care whether this argument is omitted altogether or
> not (e.g. the don't ignore second argument even if filename is
> omitted)
> 2) Solaris (for kernel name) and AROS (for module name) both assume
> that filename is the same under grub and OS. This assumption isn't
> necessarily true. These OSes are broken one way or another. If we omit
> the first argument user can workaround the problem by supplying
> kernel/module OS  image name as first argument of multiboot/module
> command line
> E.g.
> multiboot /RPOOL/opensolaris/@/platform/i86pc/kernel /platform/i86pc/kernel

I agree with this.  But please wait a few days to give everyone a chance
to read it.

Regarding the patch:

>    /* Figure out cmdline length.  */
> -  for (i = 0, cmdline_length = 0; i < argc; i++)
> +  for (i = 1, cmdline_length = 0; i < argc; i++)
>      cmdline_length += grub_strlen (argv[i]) + 1;
>  
> +  if (cmdline_length == 0)
> +    cmdline_length = 1;
> +
> 
>    boot_loader_name_length = sizeof(PACKAGE_STRING);
>  
>  #define cmdline_addr(x)		((void *) ((x) + code_size))
> @@ -351,14 +354,16 @@ grub_multiboot (int argc, char *argv[])
>    if (! cmdline)
>      goto fail;
>  
> -  for (i = 0; i < argc; i++)
> +  for (i = 1; i < argc; i++)
>      {
>        p = grub_stpcpy (p, argv[i]);
>        *(p++) = ' ';
>      }
>  
>    /* Remove the space after the last word.  */
> -  *(--p) = '\0';
> +  if (p != cmdline)
> +    p--;
> +  *p = 0;
>  
>    mbi->flags |= MULTIBOOT_INFO_CMDLINE;
>    mbi->cmdline = (grub_uint32_t) cmdline_addr (grub_multiboot_payload_dest);
> @@ -422,9 +427,12 @@ grub_module  (int argc, char *argv[])
>        goto fail;
>      }
>  
> -  for (i = 0; i < argc; i++)
> +  for (i = 1; i < argc; i++)
>      len += grub_strlen (argv[i]) + 1;
>  
> +  if (len == 0)
> +    len = 1;
> +
>    cmdline = p = grub_malloc (len);
>    if (! cmdline)
>      goto fail;
> @@ -436,7 +444,9 @@ grub_module  (int argc, char *argv[])
>      }
>  
>    /* Remove the space after the last word.  */
> -  *(--p) = '\0';
> +  if (p != cmdline)
> +    p--;
> +  *p = '\0';

There's a much simpler way to address this.  Just add something like:

  cmdline_argv = argv + 1;
  cmdline_argc = argc - 1;

at the beginning, and then use cmdline_argv and cmdline_argc instead of
correcting the off-by-one every time.

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

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

[Vladimir 'phcoder' Serbinenko]

> I agree with this.  But please wait a few days to give everyone a chance
> to read it.
>
> Regarding the patch:
>
> There's a much simpler way to address this.  Just add something like:
>
>  cmdline_argv = argv + 1;
>  cmdline_argc = argc - 1;
>
> at the beginning, and then use cmdline_argv and cmdline_argc instead of
> correcting the off-by-one every time.
Correcting the numbers is actually smaller part of the patch. The most
of it is to make empty commandlines to be handled correctly (this
couldn't happen previously)
>
> --
> 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
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

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

[Robert Millan]

On Sat, Aug 01, 2009 at 04:37:40PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> > I agree with this.  But please wait a few days to give everyone a chance
> > to read it.
> >
> > Regarding the patch:
> >
> > There's a much simpler way to address this.  Just add something like:
> >
> >  cmdline_argv = argv + 1;
> >  cmdline_argc = argc - 1;
> >
> > at the beginning, and then use cmdline_argv and cmdline_argc instead of
> > correcting the off-by-one every time.
> Correcting the numbers is actually smaller part of the patch. The most
> of it is to make empty commandlines to be handled correctly (this
> couldn't happen previously)

Either there's an extra argv member that is always present and we want
to remove, or there's the possibility that the command-line is empty.
AFAICS we can't have both problems.

argv[0] corresponds to the filename, right?  In that case, it's not possible
to run multiboot without argv[0] (or at least, we shouldn't allow it).  Then
we can remove it unconditionally.

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

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

[Vladimir 'phcoder' Serbinenko]

On Sat, Aug 1, 2009 at 5:05 PM, Robert Millan<rmh@aybabtu.com> wrote:
> On Sat, Aug 01, 2009 at 04:37:40PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> > I agree with this.  But please wait a few days to give everyone a chance
>> > to read it.
>> >
>> > Regarding the patch:
>> >
>> > There's a much simpler way to address this.  Just add something like:
>> >
>> >  cmdline_argv = argv + 1;
>> >  cmdline_argc = argc - 1;
>> >
>> > at the beginning, and then use cmdline_argv and cmdline_argc instead of
>> > correcting the off-by-one every time.
>> Correcting the numbers is actually smaller part of the patch. The most
>> of it is to make empty commandlines to be handled correctly (this
>> couldn't happen previously)
>
> Either there's an extra argv member that is always present and we want
> to remove, or there's the possibility that the command-line is empty.
> AFAICS we can't have both problems.
>
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.

> argv[0] corresponds to the filename, right?  In that case, it's not possible
> to run multiboot without argv[0] (or at least, we shouldn't allow it).  Then
> we can remove it unconditionally.
>
> --
> 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
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

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

[Robert Millan]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

On Sat, Aug 01, 2009 at 05:13:27PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> >> > There's a much simpler way to address this.  Just add something like:
> >> >
> >> >  cmdline_argv = argv + 1;
> >> >  cmdline_argc = argc - 1;
> >> >
> >> > at the beginning, and then use cmdline_argv and cmdline_argc instead of
> >> > correcting the off-by-one every time.
> >> Correcting the numbers is actually smaller part of the patch. The most
> >> of it is to make empty commandlines to be handled correctly (this
> >> couldn't happen previously)
> >
> > Either there's an extra argv member that is always present and we want
> > to remove, or there's the possibility that the command-line is empty.
> > AFAICS we can't have both problems.
> >
> 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.

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

[-- Attachment #2: cmdline.diff --]
[-- Type: text/x-diff, Size: 1067 bytes --]

Index: loader/i386/multiboot.c
===================================================================
--- loader/i386/multiboot.c	(revision 2465)
+++ loader/i386/multiboot.c	(working copy)
@@ -201,6 +201,8 @@
   grub_ssize_t len, cmdline_length, boot_loader_name_length;
   grub_uint32_t mmap_length;
   int i;
+  int cmdline_argc;
+  char **cmdline_argv;
 
   grub_loader_unset ();
 
@@ -256,9 +258,12 @@
 
   mmap_length = grub_get_multiboot_mmap_len ();
 
+  cmdline_argv = argv + 1;
+  cmdline_argc = argc - 1;
+
   /* Figure out cmdline length.  */
-  for (i = 0, cmdline_length = 0; i < argc; i++)
-    cmdline_length += grub_strlen (argv[i]) + 1;
+  for (i = 0, cmdline_length = 0; i < cmdline_argc; i++)
+    cmdline_length += grub_strlen (cmdline_argv[i]) + 1;
 
   boot_loader_name_length = sizeof(PACKAGE_STRING);
 
@@ -351,9 +356,9 @@
   if (! cmdline)
     goto fail;
 
-  for (i = 0; i < argc; i++)
+  for (i = 0; i < cmdline_argc; i++)
     {
-      p = grub_stpcpy (p, argv[i]);
+      p = grub_stpcpy (p, cmdline_argv[i]);
       *(p++) = ' ';
     }
 

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

[Vladimir 'phcoder' Serbinenko]

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



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

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

[Robert Millan]

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.

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

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

[Vladimir 'phcoder' Serbinenko]

On Mon, Aug 3, 2009 at 12:41 AM, Robert Millan<rmh@aybabtu.com> 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
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

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

[Seth Goldberg]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2383 bytes --]

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<rmh@aybabtu.com> 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
>> Grub-devel@gnu.org
>> 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
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

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

[Seth Goldberg]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2690 bytes --]

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<rmh@aybabtu.com> 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
>>> Grub-devel@gnu.org
>>> 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
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>> 
>

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

[Michal Suchanek]

2009/8/27 Seth Goldberg <Seth.Goldberg@sun.com>:
> Hi,
>
>  Any chance of having a 'multiboot1' module that can continue to pass the
> multiboot filename as arg0 ?
>

From the previous discussion of this feature I guess you can pass it
as the first argument manually.

HTH

Michal

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

[Robert Millan]

On Thu, Aug 27, 2009 at 12:55:21PM +0200, Michal Suchanek wrote:
> 2009/8/27 Seth Goldberg <Seth.Goldberg@sun.com>:
> > Hi,
> >
> >  Any chance of having a 'multiboot1' module that can continue to pass the
> > multiboot filename as arg0 ?
> >
> 
> >From the previous discussion of this feature I guess you can pass it
> as the first argument manually.

Yes.  We did this precisely so you could continue to rely on the first
argument being the kernel filename, and at the same time we wouldn't
have to make this a requirement for everyone else.

Btw, I recommend that you use grub-mkconfig to handle such things.  There's
no snippet for Solaris yet, but they're easy to write (check util/grub.d/).

In your shell script it's painless to pass the same argument twice to
multiboot command.

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

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

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]

Hello!

On Fri, Aug 14, 2009 at 05:20:09PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> Committed with improvements as ACK'ed by Robert on IRC

I wasted at least half of a working day due to this change!  (As well as
others wasted time, who where trying to help me.)

Don't get me wrong -- in principle I agree with this change, but what I
do not agree with is simply, silently! changing this behavior: you know,
there are systems that rely on the previous behavior, such as GNU/Hurd,
or the issue I was struggling with, Xen, as reported in this thread,
<http://lists.alioth.debian.org/pipermail/pkg-xen-devel/2009-October/002479.html>,
and finally here: <http://bugs.debian.org/557645>.

I have been looking in a lot of places (initramsfs, udev, lvm, ...) what
was possibly going wrong, but would not have expected that GRUB's module
would suddenly change its behavior.  Heck, I'm even on the grub-devel
mailing list, but I can't afford to read its hundreds of messages every
week.

``There is NO WARRANTY, to the extent permitted by law.'' of course, but
please think about the consequences before doing such incompatible
changes in the future.


Wouldn't it have been possible to use something like ``module --arg0 FILE
ARG0 ARG1 ...'', and ``module FILE ARG1 ...''  defaulting to ``module
--arg0 FILE FILE ARG1 ...''?


Regards,
 Thomas


PS: In general, thanks for the work all of you are doing with maintaining
    GRUB!

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

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

[Robert Millan]

On Tue, Nov 24, 2009 at 12:21:01PM +0100, Thomas Schwinge wrote:
> Hello!
> 
> On Fri, Aug 14, 2009 at 05:20:09PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> > Committed with improvements as ACK'ed by Robert on IRC
> 
> I wasted at least half of a working day due to this change!  (As well as
> others wasted time, who where trying to help me.)
> 
> Don't get me wrong -- in principle I agree with this change, but what I
> do not agree with is simply, silently! changing this behavior: you know,
> there are systems that rely on the previous behavior, such as GNU/Hurd,
> or the issue I was struggling with, Xen, as reported in this thread,
> <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/2009-October/002479.html>,
> and finally here: <http://bugs.debian.org/557645>.
> 
> I have been looking in a lot of places (initramsfs, udev, lvm, ...) what
> was possibly going wrong, but would not have expected that GRUB's module
> would suddenly change its behavior.  Heck, I'm even on the grub-devel
> mailing list, but I can't afford to read its hundreds of messages every
> week.
> 
> ``There is NO WARRANTY, to the extent permitted by law.'' of course, but
> please think about the consequences before doing such incompatible
> changes in the future.

You're right.  We should have documented this better.  Perhaps by mentioning
it in NEWS and in the release announcement.  Sorry about that.

> Wouldn't it have been possible to use something like ``module --arg0 FILE
> ARG0 ARG1 ...'', and ``module FILE ARG1 ...''  defaulting to ``module
> --arg0 FILE FILE ARG1 ...''?

We don't like to carry legacy baggage.  Backward compatibility may be fine
to keep around for a while in some cases, but in this one there really was
no sane way to do it.

> PS: In general, thanks for the work all of you are doing with maintaining
>     GRUB!

You're welcome.

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

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

[Robert Millan]

On Tue, Nov 24, 2009 at 12:34:37PM +0100, Robert Millan wrote:
> 
> You're right.  We should have documented this better.  Perhaps by mentioning
> it in NEWS and in the release announcement.  Sorry about that.

And in spite of that, both versions comply with the letter of the Multiboot
specification.  Always keep in mind, when implementing a standard you must
follow the text and not the reference implementation.  Never make any
assumptions about what an implementation can do other than what is
explicitly described in the text.

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

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

[Samuel Thibault]

Robert Millan, le Tue 24 Nov 2009 12:48:22 +0100, a écrit :
> On Tue, Nov 24, 2009 at 12:34:37PM +0100, Robert Millan wrote:
> > You're right.  We should have documented this better.  Perhaps by mentioning
> > it in NEWS and in the release announcement.  Sorry about that.
> 
> And in spite of that, both versions comply with the letter of the Multiboot
> specification.  Always keep in mind, when implementing a standard you must
> follow the text and not the reference implementation.  Never make any
> assumptions about what an implementation can do other than what is
> explicitly described in the text.

But when the standard doesn't say anything and thus you can't rely
on anything, you're doomed...  And thus you default to following the
reference implementation.

Samuel