All of lore.kernel.org
 help / color / mirror / Atom feed
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 08:54:43 +0200	[thread overview]
Message-ID: <87ac441wzw.fsf@xs4all.nl> (raw)
In-Reply-To: <Pine.LNX.4.64.0610101246320.10244@boston.corp.fedex.com> (Jeff Chua's message of "Tue, 10 Oct 2006 12:59:35 +0800 (SGT)")

Jeff Chua <jeff84@silk.corp.fedex.com> writes:

> On Mon, 9 Oct 2006, Hollis Blanchard wrote:
>
>>> Shall I use '#ifdef __linux__' to include <asm/param.h> only on linux, and
>>> '#define COMMAND_LINE_SIZE 255' for non-linux system?
>>
> 5B> Well, does this number change often? If not, let's just copy it.
>>
>> If so, then we're screwed anyways because asm/param.h would only match
>> the installed kernel's limit, so may not work for other kernel versions.
>
> You're right. asm/param.h determines the limit. We've read this from
> here for linux.
>
> The idea is that there are users out there who wants to pass quite a
> few parameters during boot, and loadlin currently handles this. I'm
> passing network address, netmask, broadcast, hostname, modules_to_load
> and boot the system up using ramdisk. This allow every system to be
> unique and yet able to boot from the same CDROM/image.
>
> So, another approach is to use "configure --CommandLineSize=1024" to
> specify the size, but I thought reading from asm/param.h would be
> easier.

I don't like limits that are introduced at compile time.  It means
that either things break when a kernel with other limits are used.  Or
that users will get binaries with limits (for example, when using a
GRUB 2 package).

--
Marco




  reply	other threads:[~2006-10-10  6:46 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 [this message]
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
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=87ac441wzw.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.