From: Marco Gerards <mgerards@xs4all.nl>
To: The development of GRUB 2 <grub-devel@gnu.org>
Cc: Jeff Chua <jchua@fedex.com>
Subject: Re: how to increase commandline size (patch + changelog)
Date: Tue, 10 Oct 2006 16:38:52 +0200 [thread overview]
Message-ID: <8764es1bib.fsf@xs4all.nl> (raw)
In-Reply-To: <Pine.LNX.4.64.0610101554340.28116@boston.corp.fedex.com> (Jeff Chua's message of "Tue, 10 Oct 2006 16:01:24 +0800 (SGT)")
Jeff Chua <jeff84@silk.corp.fedex.com> writes:
> On Tue, 10 Oct 2006, Marco Gerards wrote:
>
>> Isn't it possible to use the kernel binary to determine this? For
>> example, is the maximum commandline size stored somewhere? Perhaps,
>> we can determine it by looking at some version field? According to
>> the documentation it is has a maximum length of 255 bytes for every
>> Linux version:
>
> But, user can overwrite this to expand the commandline. It's
> documented, and tested. See
> http://www.x86-64.org/lists/discuss/msg06193.html
Well, a protocol change which is not official and an email is not
really documentation.
>> I don't want the loader to rely on being compiled on GNU/Linux. GRUB
>> 2, when compiled on *BSD, should be capable of loading Linux just as
>> GRUB 2 compiled on GNU/Linux would.
>
> Agree. So, standard 255 is ok, but then it'll be nice to allow user to
> compile "grub2" to expand the commandline. I don't know whether any
> distributions expand more than 255 characters.
Compile time arguments are not really an option to me. In that case I
prefer something run-time. Or something that can be detected at
run-time. It seems all the official versions do not make this change,
so changing this is actually non-standard.
You can not rely on the header files when compiling GRUB. Who says
the headers you use is for the kernel you load? The same is true for
compile time arguments.
So there are two things we can do:
- Detect this somehow by looking at the binary. This should be
reliable. I don't think this is possible.
- Add some run-time argument to the loader to override the command
line length. But I do not like this either because it allows
breaking the Linux boot protocol.
--
Marco
next prev parent reply other threads:[~2006-10-10 14:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-10 0:45 how to increase commandline size (fwd) Jeff Chua
2006-10-10 1:03 ` how to increase commandline size (patch + changelog) Jeff Chua
2006-10-10 2:27 ` Hollis Blanchard
2006-10-10 3:08 ` Jeff Chua
2006-10-10 4:32 ` Hollis Blanchard
2006-10-10 4:59 ` Jeff Chua
2006-10-10 6:54 ` Marco Gerards
2006-10-10 6:52 ` Marco Gerards
2006-10-10 8:01 ` Jeff Chua
2006-10-10 12:35 ` Markus Laire
2006-10-10 14:38 ` Marco Gerards [this message]
2006-10-10 15:40 ` Hollis Blanchard
2006-10-10 16:08 ` Marco Gerards
2006-10-10 17:17 ` Jeff Chua
2006-10-13 18:53 ` Yoshinori K. Okuji
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8764es1bib.fsf@xs4all.nl \
--to=mgerards@xs4all.nl \
--cc=grub-devel@gnu.org \
--cc=jchua@fedex.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.