Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[H. Peter Anvin]

Alon Bar-Lev wrote:
> 
> Hello Peter,
> 
> I am sorry that I am contacting you directly... Please refer me to 
> correct contact if you are not the one.
> 
> Lately, I've found that 256 bytes long kernel parameters are not enough 
> for my configuration. 
> 
> I've found the place where the kernel defines the length, I've actually 
> found it in two places... I cannot understand why...
> 
> include/asm-i386/param.h: #define COMMAND_LINE_SIZE 256
> include/asm-i386/setup.h: #define COMMAND_LINE_SIZE 256
> 
> Now... I've added an entry in the kernel configuration menu so that I 
> can define these constants using menuconfig. 
> 
> I was quite happy...
> 
> But then I've got into a discussion with grub's development team...
> 
> From what I've read in the Documentation/i386/boot.txt I understood 
> that if I use boot protocol 2.02+ there should be no reason for 256 byte 
> limitation on the string pointed by the cmd_line_ptr, so I guessed they 
> will deliver the command-line twice once for the old protocol truncated, 
> and once for the new protocol not truncated.
> 
> Grub and Lilo approach is to point  the cmd_line_ptr to the old 
> protocol's command line, thus truncating it to 256.
> 
> I'm just wondering... Can the 256 limit be broken, without modifying the 
> boot protocol?
> 
> I think it can... But I need a formal answer so I can push it forward.
> 

Yes, it can.  Several people on the SYSLINUX mailing list have tried 
this, and it works just fine.  The current version of SYSLINUX has a 
limit of 511 characters (because of memory management reasons inside 
SYSLINUX) instead of 255 (plus null).

I think someone on the SYSLINUX mailing list already sent a patch to 
akpm to make 512 the default; making it configurable would be a better 
idea.  Feel free to send your patch through me.

	-hpa

Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Chris Wedgwood]

On Wed, Aug 31, 2005 at 02:29:44PM -0700, H. Peter Anvin wrote:

> I think someone on the SYSLINUX mailing list already sent a patch to
> akpm to make 512 the default; making it configurable would be a
> better idea.  Feel free to send your patch through me.

So we really need this to be a configuration option?  We have too many
of those already.

Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[H. Peter Anvin]

Chris Wedgwood wrote:
> On Wed, Aug 31, 2005 at 02:29:44PM -0700, H. Peter Anvin wrote:
> 
>>I think someone on the SYSLINUX mailing list already sent a patch to
>>akpm to make 512 the default; making it configurable would be a
>>better idea.  Feel free to send your patch through me.
> 
> So we really need this to be a configuration option?  We have too many
> of those already.

Maybe not.  Another option would simply be to bump it up significantly 
(2x isn't really that much.)   4096, maybe.

	-hpa

Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Chris Wedgwood]

On Wed, Aug 31, 2005 at 03:01:57PM -0700, H. Peter Anvin wrote:

> Maybe not.  Another option would simply be to bump it up
> significantly (2x isn't really that much.)  4096, maybe.

I wonder if we're not at the point where we need something different
to what we have now.  The concept of a command-line works for passing
simple state but for more complex things it's too cumbersome.

Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Jesper Juhl]

On 9/1/05, Chris Wedgwood <cw@f00f.org> wrote:
> On Wed, Aug 31, 2005 at 03:01:57PM -0700, H. Peter Anvin wrote:
> 
> > Maybe not.  Another option would simply be to bump it up
> > significantly (2x isn't really that much.)  4096, maybe.
> 
> I wonder if we're not at the point where we need something different
> to what we have now.  The concept of a command-line works for passing
> simple state but for more complex things it's too cumbersome.

How about

a) bump the limit on the cmd line - it's still useful, and 256 really
is quite small for some things.

b) add a new boot option telling the kernel the name of some file in
initrd or similar from which to load additional options.

I don't know if b is feasible at all. It would mean that the kernel
would need to get a hold of the initrd or whatever quite early to be
able to process options from it, but if it's doable somehow it would
be a really neat thing.


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Chris Wedgwood]

On Thu, Sep 01, 2005 at 12:12:00AM +0200, Jesper Juhl wrote:

> b) add a new boot option telling the kernel the name of some file in
> initrd or similar from which to load additional options.

a file in initrd isn't a good choice; as the initrd is generally a fix
image

the point is some bootloaders might want to pass quite a bit of state
to the kernel at times (i actually have this for a mip32 target where
i construct a table and pass a pointer to that in, a tad icky but for
lack of options)

Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[H. Peter Anvin]

Chris Wedgwood wrote:
> On Thu, Sep 01, 2005 at 12:12:00AM +0200, Jesper Juhl wrote:
> 
>>b) add a new boot option telling the kernel the name of some file in
>>initrd or similar from which to load additional options.
> 
> a file in initrd isn't a good choice; as the initrd is generally a fix
> image
> 
> the point is some bootloaders might want to pass quite a bit of state
> to the kernel at times (i actually have this for a mip32 target where
> i construct a table and pass a pointer to that in, a tad icky but for
> lack of options)

initrd is a fixed image, but initramfs can be synthesized.

	-hpa

Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Jesper Juhl]

On 9/1/05, Chris Wedgwood <cw@f00f.org> wrote:
> On Thu, Sep 01, 2005 at 12:12:00AM +0200, Jesper Juhl wrote:
> 
> > b) add a new boot option telling the kernel the name of some file in
> > initrd or similar from which to load additional options.
> 
> a file in initrd isn't a good choice; as the initrd is generally a fix
> image
> 
> the point is some bootloaders might want to pass quite a bit of state
> to the kernel at times (i actually have this for a mip32 target where
> i construct a table and pass a pointer to that in, a tad icky but for
> lack of options)
> 
Well, it wouldn't have to be initrd specifically. Generally what's
needed is *some* way to tell the kernel "please read more options from
location <foo>". The interresting bit is what <foo>'s supposed to be.


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[H. Peter Anvin]

Jesper Juhl wrote:
> 
> Well, it wouldn't have to be initrd specifically. Generally what's
> needed is *some* way to tell the kernel "please read more options from
> location <foo>". The interresting bit is what <foo>'s supposed to be.
> 

This is what initramfs (as opposed to initrd) does quite well.

	-hpa

Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Alon Bar-Lev]

Thank you all for your quick responses!

I want to add some of my comments.


1. Kernel parameters is a great mechanism to control how the kernel 
behaves without modifying any file in kernel,

putting options in a file maybe seems a good solution... but it lower 
the power of the boot loader,

which can be used to control the kernel externally.


So I think we should solve the 256 limitation... And not adding a new 
mechanism.


2. As I understand initramfs gradually replaces initrd, since all the 
user space applications needs initramfs,

So modifying the initramfs to be different at each machine is not good 
for maintenance, and not easy to

control as editing its contents as in the boot loader approach.


3. Adding the maximum limit as configuration option is needed since the 
kernel allocates a static memory buffer,

As such, it should be determined... I think the default should be at 
least 1024... But I don't like

hard coded constants to be written in source.


4. "The concept of a command-line works for passing simple state but for 
more complex things it's too cumbersome."

I don't agree with that... the term "simple" is user defined...


For example, I use the command-line to do the following:

a. Report kernel of my root partition.

b. Report kernel of my root partition type.

c. Report my initramfs of my swap partition, boot partition, root partition.

d. Report my initramfs of where to find decryption key.

e. Report kernel+initramfs of which bootsplash to use and what resolution.

f. Set my initramfs debug level.

g. Set silent console output tty.

h. Set initial loop device number for decryption.


This all must happen at boot, and I needed to squeeze the names of the 
arguments in

order them to feet 256 limitation...

Does it fall in the "simple definition"?


5. In order for Lilo and Grub to implement the 2.02+ protocol without 
truncating the command line,

I need a definite response that they should not do that... Can you 
please provide it...?

It would be best if you update the boot.txt document.

Since without boot loader support, we cannot break this limitation for 
ordinary users.


6. A minor issue... Why the COMMAND_LINE_SIZE is defined in two files? 
Is there a specific reason?


Best Regards,

Alon Bar-Lev.



H. Peter Anvin wrote:

> Jesper Juhl wrote:
>
>>
>> Well, it wouldn't have to be initrd specifically. Generally what's
>> needed is *some* way to tell the kernel "please read more options from
>> location <foo>". The interresting bit is what <foo>'s supposed to be.
>>
>
> This is what initramfs (as opposed to initrd) does quite well.
>
>     -hpa
>
>

Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[H. Peter Anvin]

Chris Wedgwood wrote:
> On Wed, Aug 31, 2005 at 03:01:57PM -0700, H. Peter Anvin wrote:
> 
>>Maybe not.  Another option would simply be to bump it up
>>significantly (2x isn't really that much.)  4096, maybe.
> 
> I wonder if we're not at the point where we need something different
> to what we have now.  The concept of a command-line works for passing
> simple state but for more complex things it's too cumbersome.

Well, we have initramfs for the really big stuff.  The kernel shouldn't 
really need that much data, though.

	-hpa

Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Chris Wedgwood]

On Wed, Aug 31, 2005 at 03:12:58PM -0700, H. Peter Anvin wrote:

> Well, we have initramfs for the really big stuff.  The kernel
> shouldn't really need that much data, though.

except the initrd image is in many cases fairly fixed; right now i
have options i pass into initramfs by passing arguments on the command
line which initrd them reads, parses and uses that to grab a file from
the network

it's a tad disconnected to have to do this though

Re: [syslinux] Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Peter Jones]

On Wed, 2005-08-31 at 15:07 -0700, Chris Wedgwood wrote:
> On Wed, Aug 31, 2005 at 03:01:57PM -0700, H. Peter Anvin wrote:
> 
> > Maybe not.  Another option would simply be to bump it up
> > significantly (2x isn't really that much.)  4096, maybe.
> 
> I wonder if we're not at the point where we need something different
> to what we have now.  The concept of a command-line works for passing
> simple state but for more complex things it's too cumbersome.

Well, for things that don't have to be done while the kernel is loading,
it's entirely possible to do more complex things in initramfs.  Form a
second image that's got a config file in it, and make the initramfs's
init set things up based on that.

But obviously that only works for things that are tweakable from
userland.
-- 
  Peter

Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Alon Bar-Lev]

H. Peter Anvin wrote:
> Chris Wedgwood wrote:
> 
>> On Wed, Aug 31, 2005 at 02:29:44PM -0700, H. Peter Anvin wrote:
>>
>>> I think someone on the SYSLINUX mailing list already sent a patch to
>>> akpm to make 512 the default; making it configurable would be a
>>> better idea.  Feel free to send your patch through me.
>>
>>
>> So we really need this to be a configuration option?  We have too many
>> of those already.
> 
> 
> Maybe not.  Another option would simply be to bump it up significantly 
> (2x isn't really that much.)   4096, maybe.
> 
>     -hpa
> 

Hello Peter, I've written a reply before but got no response...

The idea of putting arguments in initramfs is not practical, 
since the whole idea is to have the same image of system and 
affecting its behavior using the boot loader...

I would like to push forward the idea to extend the 
command-line size...

All we need for start is an updated version of the "THE 
LINUX/I386 BOOT PROTOCOL" document that states that in the 
2.02+  protocol the boot loader should set cmd_line_ptr to a 
pointer to a null terminated string without any size 
restriction, specifying that the kernel will read as much as 
it can.

After I get this update, I will try to work with GRUB and LILO 
so that they will fix their implementation. Currently they 
claim that they understand that they should truncate the 
string to 256.

After that I will provide my simple  patch for setting the 
maximum size the kernel allocates in the configuration.

BTW: Do you know why the COMMAND_LINE_SIZE constant is located 
in two separate include files?

Best Regards,
Alon Bar-Lev.

Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[H. Peter Anvin]

Alon Bar-Lev wrote:
> 
> Hello Peter, I've written a reply before but got no response...
> 
> The idea of putting arguments in initramfs is not practical, since the 
> whole idea is to have the same image of system and affecting its 
> behavior using the boot loader...
> 

No, you're wrong.  The boot loader can synthesize an initramfs.

> I would like to push forward the idea to extend the command-line size...
> 
> All we need for start is an updated version of the "THE LINUX/I386 BOOT 
> PROTOCOL" document that states that in the 2.02+  protocol the boot 
> loader should set cmd_line_ptr to a pointer to a null terminated string 
> without any size restriction, specifying that the kernel will read as 
> much as it can.

Already pushed to Andrew.  I will follow it up with a patch to extend 
the command line, at least to 512.

> After I get this update, I will try to work with GRUB and LILO so that 
> they will fix their implementation. Currently they claim that they 
> understand that they should truncate the string to 256.
> 
> After that I will provide my simple  patch for setting the maximum size 
> the kernel allocates in the configuration.
> 
> BTW: Do you know why the COMMAND_LINE_SIZE constant is located in two 
> separate include files?

No, I don't.  It could be because one is included from assembly code in 
the i386 architecture.

	-hpa

Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Alon Bar-Lev]

Thank you for the reply,

H. Peter Anvin wrote:
> Alon Bar-Lev wrote:
> 
>>
>> Hello Peter, I've written a reply before but got no response...
>>
>> The idea of putting arguments in initramfs is not practical, since the 
>> whole idea is to have the same image of system and affecting its 
>> behavior using the boot loader...
>>
> 
> No, you're wrong.  The boot loader can synthesize an initramfs.

Hmm... Isn't it somewhat big change for them?
Do you mean that they can add a text file at root containing 
the command-line?
It is not so good... Since currently many scripts looks at 
/proc/cmdline and get the arguments they are interested in... 
The initramfs will not allow this... And there is no access to 
initramfs files after control is passed to root, since most 
distributions erase its contents in order to free memory...

> 
> Already pushed to Andrew.  I will follow it up with a patch to extend 
> the command line, at least to 512.

Thanks!!!
But why not making it a configuration option?
For example, I think it should be at least 1024...

Will this patch update the document?
If it does please don't specify maximum size,
The boot loader should be instructed to put unlimited 
string... OK... there is no thing like unlimited, so max 16K :)

Only the kernel should truncate it to the right size.

Best Regards,
Alon Bar-Lev.

Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Georg Lippold]

Hi,

what's the status of this? linux-2.6.14-rc3 still has 256 chars limit. A 
quick fix to 1024 would help a lot. Other Platforms have up to 4096...

Greetings,

Georg

[PATCH] Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Georg Lippold]

Hello Peter,

my first post didn't get any attention, maybe it was too short.
Here's a longer version:

hpa@zytor.com wrote on Sept. 6th, 2005:

[ wrt. COMMAND_LINE_SIZE=256 in linux/include/asm-i386/setup.h and 
linux/include/asm-i386/param.h ]

>> I would like to push forward the idea to extend the command-line size...
> [...]
> Already pushed to Andrew.  I will follow it up with a patch to extend 
> the command line, at least to 512.

I would like to know the status of this. In linux-2.6.14-rc3 the 
COMMAND_LINE_SIZE is still 256 chars long.

Here's a patch to fix that to 1024.

Signed-off-by: Georg Lippold <lippold@uni-bremen.de>

--- linux/include/asm-i386/param.h~ 2005-09-21 23:32:23.000000000 +0200
+++ linux/include/asm-i386/param.h  2005-10-10 14:39:34.000000000 +0200
@@ -18,6 +18,6 @@
  #endif

  #define MAXHOSTNAMELEN 64      /* max length of hostname */
-#define COMMAND_LINE_SIZE 256
+#define COMMAND_LINE_SIZE 1024

  #endif
--- linux/include/asm-i386/setup.h~ 2005-10-10 14:39:18.000000000 +0200
+++ linux/include/asm-i386/setup.h  2005-10-10 14:39:45.000000000 +0200
@@ -17,7 +17,7 @@
  #define MAX_NONPAE_PFN (1 << 20)

  #define PARAM_SIZE 4096
-#define COMMAND_LINE_SIZE 256
+#define COMMAND_LINE_SIZE 1024

  #define OLD_CL_MAGIC_ADDR      0x90020
  #define OLD_CL_MAGIC           0xA33F

Re: [PATCH] Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Jesper Juhl]

On 10/10/05, Georg Lippold <georg.lippold@gmx.de> wrote:
> Hello Peter,
>
> my first post didn't get any attention, maybe it was too short.
> Here's a longer version:
>
> hpa@zytor.com wrote on Sept. 6th, 2005:
>
> [ wrt. COMMAND_LINE_SIZE=256 in linux/include/asm-i386/setup.h and
> linux/include/asm-i386/param.h ]
>
> >> I would like to push forward the idea to extend the command-line size...
> > [...]
> > Already pushed to Andrew.  I will follow it up with a patch to extend
> > the command line, at least to 512.
>
> I would like to know the status of this. In linux-2.6.14-rc3 the
> COMMAND_LINE_SIZE is still 256 chars long.
>
> Here's a patch to fix that to 1024.
>

What about the other archs ?

include/asm/setup.h:#define COMMAND_LINE_SIZE 256
include/asm/param.h:#define COMMAND_LINE_SIZE 256
include/asm-m68knommu/setup.h:#define COMMAND_LINE_SIZE 512
include/asm-powerpc/setup.h:#define COMMAND_LINE_SIZE   512
include/asm-sh/setup.h:#define COMMAND_LINE_SIZE 256
include/asm-um/setup.h:#define COMMAND_LINE_SIZE 4096
include/asm-parisc/setup.h:#define COMMAND_LINE_SIZE    1024
include/asm-x86_64/setup.h:#define COMMAND_LINE_SIZE    256
include/asm-xtensa/setup.h:#define COMMAND_LINE_SIZE    256
include/asm-alpha/setup.h:#define COMMAND_LINE_SIZE     256
include/asm-arm26/setup.h:#define COMMAND_LINE_SIZE 1024
include/asm-h8300/setup.h:#define COMMAND_LINE_SIZE     512
include/asm-sparc/setup.h:#define COMMAND_LINE_SIZE     256
include/asm-i386/setup.h:#define COMMAND_LINE_SIZE 256
include/asm-i386/param.h:#define COMMAND_LINE_SIZE 256
include/asm-cris/setup.h:#define COMMAND_LINE_SIZE      256
include/asm-m32r/setup.h:#define COMMAND_LINE_SIZE      (512)
include/asm-ia64/setup.h:#define COMMAND_LINE_SIZE      512
include/asm-m68k/setup.h:#define COMMAND_LINE_SIZE      CL_SIZE
include/asm-mips/setup.h:#define COMMAND_LINE_SIZE      256
include/asm-mips/bootinfo.h:#define CL_SIZE                    
COMMAND_LINE_SIZE
include/asm-s390/setup.h:#define COMMAND_LINE_SIZE      896
include/asm-v850/setup.h:#define COMMAND_LINE_SIZE      512
include/asm-sh64/setup.h:#define COMMAND_LINE_SIZE 256
include/asm-arm/setup.h:#define COMMAND_LINE_SIZE 1024
include/asm-frv/param.h:#define COMMAND_LINE_SIZE       512
include/asm-sparc64/setup.h:#define COMMAND_LINE_SIZE   256

Would it make sense to make it 1024 everywhere (and maybe move it out
of arch specific files and just set it in one central place) ?


--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [PATCH] Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Alon Bar-Lev]

Hello,

1. Why don't you put this variable at config, and allow the user to
specify the length during configuration? I have a patch that does just
that.

2. THE MOST IMPORTANT task is to update the documentation at
i386/boot.txt so that it will state that boot protocol 2.02+ field
cmd_line_ptr should not be truncated and can be up to 4K bytes.
Also fix "The kernel command line is null-terminated string up to 255
characters long,..." this is good for the old boot protocol, but not
for the 2.02+ protocol.

Without this fix the bootloaders (Lilo, Grub) will not fix their
code... So that users will still will not be able to use > 256 command
line.

I've opened bug at Grub... and I wait for the documentation update so
that they will modify their behaviour of truncating the cmd_line_ptr
to 256.

Best Regards,
Alon Bar-Lev.


On 10/10/05, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> On 10/10/05, Georg Lippold <georg.lippold@gmx.de> wrote:
> > Hello Peter,
> >
> > my first post didn't get any attention, maybe it was too short.
> > Here's a longer version:
> >
> > hpa@zytor.com wrote on Sept. 6th, 2005:
> >
> > [ wrt. COMMAND_LINE_SIZE=256 in linux/include/asm-i386/setup.h and
> > linux/include/asm-i386/param.h ]
> >
> > >> I would like to push forward the idea to extend the command-line size...
> > > [...]
> > > Already pushed to Andrew.  I will follow it up with a patch to extend
> > > the command line, at least to 512.
> >
> > I would like to know the status of this. In linux-2.6.14-rc3 the
> > COMMAND_LINE_SIZE is still 256 chars long.
> >
> > Here's a patch to fix that to 1024.
> >
>
> What about the other archs ?
>
> include/asm/setup.h:#define COMMAND_LINE_SIZE 256
> include/asm/param.h:#define COMMAND_LINE_SIZE 256
> include/asm-m68knommu/setup.h:#define COMMAND_LINE_SIZE 512
> include/asm-powerpc/setup.h:#define COMMAND_LINE_SIZE   512
> include/asm-sh/setup.h:#define COMMAND_LINE_SIZE 256
> include/asm-um/setup.h:#define COMMAND_LINE_SIZE 4096
> include/asm-parisc/setup.h:#define COMMAND_LINE_SIZE    1024
> include/asm-x86_64/setup.h:#define COMMAND_LINE_SIZE    256
> include/asm-xtensa/setup.h:#define COMMAND_LINE_SIZE    256
> include/asm-alpha/setup.h:#define COMMAND_LINE_SIZE     256
> include/asm-arm26/setup.h:#define COMMAND_LINE_SIZE 1024
> include/asm-h8300/setup.h:#define COMMAND_LINE_SIZE     512
> include/asm-sparc/setup.h:#define COMMAND_LINE_SIZE     256
> include/asm-i386/setup.h:#define COMMAND_LINE_SIZE 256
> include/asm-i386/param.h:#define COMMAND_LINE_SIZE 256
> include/asm-cris/setup.h:#define COMMAND_LINE_SIZE      256
> include/asm-m32r/setup.h:#define COMMAND_LINE_SIZE      (512)
> include/asm-ia64/setup.h:#define COMMAND_LINE_SIZE      512
> include/asm-m68k/setup.h:#define COMMAND_LINE_SIZE      CL_SIZE
> include/asm-mips/setup.h:#define COMMAND_LINE_SIZE      256
> include/asm-mips/bootinfo.h:#define CL_SIZE
> COMMAND_LINE_SIZE
> include/asm-s390/setup.h:#define COMMAND_LINE_SIZE      896
> include/asm-v850/setup.h:#define COMMAND_LINE_SIZE      512
> include/asm-sh64/setup.h:#define COMMAND_LINE_SIZE 256
> include/asm-arm/setup.h:#define COMMAND_LINE_SIZE 1024
> include/asm-frv/param.h:#define COMMAND_LINE_SIZE       512
> include/asm-sparc64/setup.h:#define COMMAND_LINE_SIZE   256
>
> Would it make sense to make it 1024 everywhere (and maybe move it out
> of arch specific files and just set it in one central place) ?
>
>
> --
> Jesper Juhl <jesper.juhl@gmail.com>
> Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
> Plain text mails only, please      http://www.expita.com/nomime.html
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [PATCH] Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Georg Lippold]

Hi,

Alon Bar-Lev wrote:
> 1. Why don't you put this variable at config, and allow the user to
> specify the length during configuration? I have a patch that does just
> that.

If you'd post it, it would probably get more attention :)

> 2. THE MOST IMPORTANT task is to update the documentation at
> i386/boot.txt so that it will state that boot protocol 2.02+ field
> cmd_line_ptr should not be truncated and can be up to 4K bytes.
> Also fix "The kernel command line is null-terminated string up to 255
> characters long,..." this is good for the old boot protocol, but not
> for the 2.02+ protocol.
> 
> Without this fix the bootloaders (Lilo, Grub) will not fix their
> code... So that users will still will not be able to use > 256 command
> line.

syslinux >=3.09 supports 512 chars.

Greetings,

Georg

Re: [PATCH] Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Alon Bar-Lev]

On 10/10/05, Georg Lippold <georg.lippold@gmx.de> wrote:
> Hi,
>
> > 1. Why don't you put this variable at config, and allow the user to
> > specify the length during configuration? I have a patch that does just
> > that.
> If you'd post it, it would probably get more attention :)

I got enough attention... I just wait for documentation update... This
is the important mile-stone for this change...

> > 2. THE MOST IMPORTANT task is to update the documentation at
> > Without this fix the bootloaders (Lilo, Grub) will not fix their
> > code... So that users will still will not be able to use > 256 command
> > line.
>
> syslinux >=3.09 supports 512 chars.

Unless the documentation will be updated and it will be clear that the
boot protocol allows long command-line strings that are truncated by
the kernel at max, this task is not finished... the fact that there is
one bootloader that does that is not enough... Regardless... 512 bytes
is too small...

Best Regards,
Alon Bar-Lev.

Re: [PATCH] Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[H. Peter Anvin]

Jesper Juhl wrote:
> 
> Would it make sense to make it 1024 everywhere (and maybe move it out
> of arch specific files and just set it in one central place) ?
> 

I would agree with that, *BUT* the boot protocol on each architecture 
need to be consistent.

At the very least, though, i386 and x86-64 need to be changed together, 
since they use the same bootstrap.

	-hpa

Re: [PATCH] Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Alon Bar-Lev]

On 10/10/05, H. Peter Anvin <hpa@zytor.com> wrote:
> Jesper Juhl wrote:
> >
> > Would it make sense to make it 1024 everywhere (and maybe move it out
> > of arch specific files and just set it in one central place) ?
> >
>
> I would agree with that, *BUT* the boot protocol on each architecture
> need to be consistent.
>
> At the very least, though, i386 and x86-64 need to be changed together,
> since they use the same bootstrap.
>

Great!
Will you update the documentation of all?
After that I can try to convince bootloaders fix their code...

Best Regards,
Alon Bar-Lev.

Re: [PATCH] Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[H. Peter Anvin]

Alon Bar-Lev wrote:
> On 10/10/05, H. Peter Anvin <hpa@zytor.com> wrote:
> 
>>Jesper Juhl wrote:
>>
>>>Would it make sense to make it 1024 everywhere (and maybe move it out
>>>of arch specific files and just set it in one central place) ?
>>>
>>
>>I would agree with that, *BUT* the boot protocol on each architecture
>>need to be consistent.
>>
>>At the very least, though, i386 and x86-64 need to be changed together,
>>since they use the same bootstrap.
> 
> Great!
> Will you update the documentation of all?
> After that I can try to convince bootloaders fix their code...
> 

You have a funny way of assigning people action items.

	-hpa

Re: [PATCH] Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Alon Bar-Lev]

H. Peter Anvin wrote:
> 
> You have a funny way of assigning people action items.
> 

I am sorry... But... You are the author of this document, right?

                      THE LINUX/I386 BOOT PROTOCOL
                      ----------------------------

                     H. Peter Anvin <hpa@zytor.com>
                         Last update 2002-01-01

Do you want me yo suggest the update? I will be glad!

I don't really understand (yet) how you guys working... I am 
learning... So please help me understand.

Best Regards,
Alon Bar-Lev.

Re: [PATCH] Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Bernd Petrovitsch]

On Mon, 2005-10-10 at 18:23 +0200, Alon Bar-Lev wrote:
[...]
> Do you want me yo suggest the update? I will be glad!
                    ^^^^^^^
Probably.

> I don't really understand (yet) how you guys working... I am 
> learning... So please help me understand.

1) You want something changed, you propse a (tested) patch which
   actually changes the code you want. And then be prepared that
2) (at least) the maintaniners of concerned
   drivers/architectures/subsystems may have some seriuos problems with
   the direction your patch points to (let alone coding style).
3) Then you update/improve your patch.
4) Goto 1 until the patch is accepted or you withdraw it.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: [PATCH] Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Georg Lippold]

H. Peter Anvin wrote:
>>
>> Would it make sense to make it 1024 everywhere (and maybe move it out
>> of arch specific files and just set it in one central place) ?
>>
> 
> I would agree with that, *BUT* the boot protocol on each architecture
> need to be consistent.

> At the very least, though, i386 and x86-64 need to be changed together,
> since they use the same bootstrap.

I think it will take rather long to synchronize all archs. Maybe x86 can
fix it fast (it would ease the making of LiveCD's) and then initiate a
standardization on lkml? Knoppix has its kernel patch for over a year
now and I asked gentoo to do so, too. But they said, I should ask for it
here... Until the fix is in the distributions-kernel, probably another
month will pass and it obviously needs to be fixed.

Greetings,

Georg

Re: [PATCH] Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[H. Peter Anvin]

Georg Lippold wrote:
> 
>>At the very least, though, i386 and x86-64 need to be changed together,
>>since they use the same bootstrap.
> 
> I think it will take rather long to synchronize all archs. Maybe x86 can
> fix it fast (it would ease the making of LiveCD's) and then initiate a
> standardization on lkml? Knoppix has its kernel patch for over a year
> now and I asked gentoo to do so, too. But they said, I should ask for it
> here... Until the fix is in the distributions-kernel, probably another
> month will pass and it obviously needs to be fixed.
> 

I would suggest updating your patch to include x86-64 and documentation, 
and submit it.  Other architectures will have to do this as it suits them.

	-hpa

[PATCH 1/1] 2.6.14-rc3 x86: COMMAND_LINE_SIZE

[Georg Lippold]

H. Peter Anvin wrote on Mon, Oct 10, 2005 at 08:49:04AM -0700:
> I would suggest updating your patch to include x86-64 and documentation, 
> and submit it.  Other architectures will have to do this as it suits them.

As requested.

Signed-off-by: Georg Lippold <georg.lippold@gmx.de>

diff -ur linux~/Documentation/i386/boot.txt linux/Documentation/i386/boot.txt
--- linux~/Documentation/i386/boot.txt  2005-09-30 23:17:35.000000000 +0200
+++ linux/Documentation/i386/boot.txt   2005-10-10 18:53:11.000000000 +0200
@@ -236,7 +236,7 @@
 below.

 The kernel command line is a null-terminated string currently up to
-255 characters long, plus the final null.  A string that is too long
+1023 characters long, plus the final null.  A string that is too long
 will be automatically truncated by the kernel, a boot loader may allow
 a longer command line to be passed to permit future kernels to extend
 this limit.
diff -ur linux~/Documentation/x86_64/boot-options.txt linux/Documentation/x86_64/boot-options.txt
--- linux~/Documentation/x86_64/boot-options.txt        2005-09-30 23:17:35.000000000 +0200
+++ linux/Documentation/x86_64/boot-options.txt 2005-10-10 18:55:26.000000000 +0200
@@ -3,6 +3,9 @@
 There are many others (usually documented in driver documentation), but
 only the AMD64 specific ones are listed here.

+The kernel command line (/proc/cmdline) can have up to 1023 characters
+plus the terminating \0.
+
 Machine check

    mce=off disable machine check
diff -ur linux~/include/asm-i386/param.h linux/include/asm-i386/param.h
--- linux~/include/asm-i386/param.h     2005-09-30 23:17:35.000000000 +0200
+++ linux/include/asm-i386/param.h      2005-10-10 18:50:43.000000000 +0200
@@ -20,6 +20,6 @@
 #endif

 #define MAXHOSTNAMELEN 64      /* max length of hostname */
-#define COMMAND_LINE_SIZE 256
+#define COMMAND_LINE_SIZE 1024

 #endif
diff -ur linux~/include/asm-i386/setup.h linux/include/asm-i386/setup.h
--- linux~/include/asm-i386/setup.h     2005-09-30 23:17:35.000000000 +0200
+++ linux/include/asm-i386/setup.h      2005-10-10 18:50:09.000000000 +0200
@@ -17,7 +17,7 @@
 #define MAX_NONPAE_PFN (1 << 20)

 #define PARAM_SIZE 4096
-#define COMMAND_LINE_SIZE 256
+#define COMMAND_LINE_SIZE 1024

 #define OLD_CL_MAGIC_ADDR      0x90020
 #define OLD_CL_MAGIC           0xA33F
diff -ur linux~/include/asm-x86_64/setup.h linux/include/asm-x86_64/setup.h
--- linux~/include/asm-x86_64/setup.h   2005-09-30 23:17:35.000000000 +0200
+++ linux/include/asm-x86_64/setup.h    2005-10-10 18:51:19.000000000 +0200
@@ -1,6 +1,6 @@
 #ifndef _x8664_SETUP_H
 #define _x8664_SETUP_H

-#define COMMAND_LINE_SIZE      256
+#define COMMAND_LINE_SIZE      1024

 #endif

Re: [PATCH 1/1] 2.6.14-rc3 x86: COMMAND_LINE_SIZE

[Alon Bar-Lev]

Georg Lippold wrote:
> H. Peter Anvin wrote on Mon, Oct 10, 2005 at 08:49:04AM -0700:
> 
>>I would suggest updating your patch to include x86-64 and documentation, 

Hi!

Just a few suggestions...

1. The old protocol must stay with 255 + null command 
line... I suggest:

For boot protocol <2.02, the kernel command line is a 
null-terminated string up to 255 characters long, plus the 
final null. For boot protocol >=2.02 command line that is 
referred by cmd_line_ptr is null-terminated string, the 
kernel will truncate this string if it is too large to handle.

2. I suggest adding a new configuration to set the size of 
command-line, so it won't be hard coded...

Add CONFIG_CMD_LINE_SIZE with default of 1024.

I've done this by init/Kconfig...

--- Kconfig     2005-10-10 20:16:14.000000000 +0200
+++ Kconfig.org 2005-10-10 20:14:13.000000000 +0200
@@ -77,13 +77,6 @@ config LOCALVERSION
           object and source tree, in that order.  Your 
total string can
           be a maximum of 64 characters.

+config CMD_LINE_SIZE
+       integer "Set maximum command line size"
+       default 1024
+       help
+         This option allows you to specify the maximum 
kernel command
+         line arguments.
+
  config SWAP
         bool "Support for paging of anonymous memory (swap)"
         depends on MMU

3. Set the COMMAND_LINE_SIZE to CONFIG_CMD_LINE_SIZE

I've found that not all files that includes setup.h and 
param.h include config.h... So I've written:

#if defined(CONFIG_CMD_LINE_SIZE)
#define COMMAND_LINE_SIZE CONFIG_CMD_LINE_SIZE
#endif

So that it fails if you try to use COMMAND_LINE_SIZE and did 
not include config.h, another alternative is to include 
config.h in these include files... I don't know what the 
conventions are.

Best Regards,
Alon Bar-Lev.

Re: [PATCH 1/1] 2.6.14-rc3 x86: COMMAND_LINE_SIZE

[Georg Lippold]

Hi Alon,

Alon Bar-Lev wrote:
> For boot protocol <2.02, the kernel command line is a null-terminated
> string up to 255 characters long, plus the final null. For boot protocol
>>=2.02 command line that is referred by cmd_line_ptr is null-terminated
> string, the kernel will truncate this string if it is too large to handle.

Thus, someone could use bootloaders to "patch" the kernel: If the
bootloader writes a string of arbitary length to some memory region,
then there is a fair chance that if you make the string just long
enough, the kernel image gets (partly) overwritten. It resembles a bit
"Smashing the stack for fun and profit", but this time, it's "Rewriting
the kernel to your own needs via the bootloader on x86" :)

Same thing for user defined COMMAND_LINE_SIZE. I think that a common
interface for boot loaders is required. Especially in uncontrolled multi
user environments like Universities, everything else could lead to
undesired results.

Greetings,

Georg

Re: [PATCH 1/1] 2.6.14-rc3 x86: COMMAND_LINE_SIZE

[Alon Bar-Lev]

On 10/10/05, Georg Lippold <georg.lippold@gmx.de> wrote:
>
> Thus, someone could use bootloaders to "patch" the kernel: If the
> bootloader writes a string of arbitary length to some memory region,
> then there is a fair chance that if you make the string just long
> enough, the kernel image gets (partly) overwritten. It resembles a bit
> "Smashing the stack for fun and profit", but this time, it's "Rewriting
> the kernel to your own needs via the bootloader on x86" :)
>
> Same thing for user defined COMMAND_LINE_SIZE. I think that a common
> interface for boot loaders is required. Especially in uncontrolled multi
> user environments like Universities, everything else could lead to
> undesired results.
>

But the address of cmd_line_ptr is defined to be from the end of the
setup to 0xa0000. This is well defined, since the boot loader will
load the kernel, initramfs and cmd_line_ptr to the correct place...
Nothing is overwritten... Then the kernel is up and takes as much as
it needs from cmd_line_ptr.

Best Regards,
Alon Bar-Lev

Re: [PATCH 1/1] 2.6.14-rc3 x86: COMMAND_LINE_SIZE

[Georg Lippold]

Alon Bar-Lev wrote:
> But the address of cmd_line_ptr is defined to be from the end of the
> setup to 0xa0000. This is well defined, since the boot loader will
> load the kernel, initramfs and cmd_line_ptr to the correct place...
> Nothing is overwritten... Then the kernel is up and takes as much as
> it needs from cmd_line_ptr.

OK, then: Update my patch if you want to and resubmit it. I would like
to get this through as quickly as possible.

Greetings,

Georg

Re: [PATCH 1/1] 2.6.14-rc3 x86: COMMAND_LINE_SIZE

[Alon Bar-Lev]

Georg Lippold wrote:
> Alon Bar-Lev wrote:
> 
>>But the address of cmd_line_ptr is defined to be from the end of the
>>setup to 0xa0000. This is well defined, since the boot loader will
>>load the kernel, initramfs and cmd_line_ptr to the correct place...
>>Nothing is overwritten... Then the kernel is up and takes as much as
>>it needs from cmd_line_ptr.
> 
> 
> OK, then: Update my patch if you want to and resubmit it. I would like
> to get this through as quickly as possible.
> 
> Greetings,
> 
> Georg
> 

OK...
Here it goes...
I don't have git...
I hope it is enough...

diff -urNp linux-2.6.13.4.org/Documentation/i386/boot.txt 
linux-2.6.13.4/Documentation/i386/boot.txt
--- linux-2.6.13.4.org/Documentation/i386/boot.txt 
2005-10-10 20:54:29.000000000 +0200
+++ linux-2.6.13.4/Documentation/i386/boot.txt	2005-10-11 
19:01:40.000000000 +0200
@@ -230,12 +230,13 @@ loader to communicate with the kernel.
  relevant to the boot loader itself, see "special command 
line options"
  below.

-The kernel command line is a null-terminated string up to 255
-characters long, plus the final null.
+If the boot protocol version is 2.01 or older, the kernel 
command line is
+a null-terminated string up to 255 characters long, plus 
the final null.

  If the boot protocol version is 2.02 or later, the address 
of the
  kernel command line is given by the header field 
cmd_line_ptr (see
-above.)
+above.), the kernel may truncate this string if it is too long
+for handle.

  If the protocol version is *not* 2.02 or higher, the kernel
  command line is entered using the following protocol:
diff -urNp linux-2.6.13.4.org/include/asm-i386/param.h 
linux-2.6.13.4/include/asm-i386/param.h
--- linux-2.6.13.4.org/include/asm-i386/param.h	2005-10-10 
20:54:29.000000000 +0200
+++ linux-2.6.13.4/include/asm-i386/param.h	2005-10-11 
19:08:42.000000000 +0200
@@ -20,6 +20,5 @@
  #endif

  #define MAXHOSTNAMELEN	64	/* max length of hostname */
-#define COMMAND_LINE_SIZE 256

  #endif
diff -urNp linux-2.6.13.4.org/include/asm-i386/setup.h 
linux-2.6.13.4/include/asm-i386/setup.h
--- linux-2.6.13.4.org/include/asm-i386/setup.h	2005-10-10 
20:54:29.000000000 +0200
+++ linux-2.6.13.4/include/asm-i386/setup.h	2005-10-11 
19:10:46.000000000 +0200
@@ -17,7 +17,10 @@
  #define MAX_NONPAE_PFN	(1 << 20)

  #define PARAM_SIZE 4096
-#define COMMAND_LINE_SIZE 256
+
+#ifdef CONFIG_COMMAND_LINE_MAX_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_MAX_SIZE
+#endif

  #define OLD_CL_MAGIC_ADDR	0x90020
  #define OLD_CL_MAGIC		0xA33F
diff -urNp linux-2.6.13.4.org/include/asm-x86_64/setup.h 
linux-2.6.13.4/include/asm-x86_64/setup.h
--- linux-2.6.13.4.org/include/asm-x86_64/setup.h	2005-10-10 
20:54:29.000000000 +0200
+++ linux-2.6.13.4/include/asm-x86_64/setup.h	2005-10-11 
19:21:18.000000000 +0200
@@ -1,6 +1,8 @@
  #ifndef _x8664_SETUP_H
  #define _x8664_SETUP_H

-#define COMMAND_LINE_SIZE	256
+#ifdef CONFIG_COMMAND_LINE_MAX_SIZE
+#define COMMAND_LINE_SIZE	CONFIG_COMMAND_LINE_MAX_SIZE
+#endif

  #endif
diff -urNp linux-2.6.13.4.org/init/Kconfig 
linux-2.6.13.4/init/Kconfig
--- linux-2.6.13.4.org/init/Kconfig	2005-10-10 
20:54:29.000000000 +0200
+++ linux-2.6.13.4/init/Kconfig	2005-10-11 
19:20:23.000000000 +0200
@@ -77,6 +77,13 @@ config LOCALVERSION
  	  object and source tree, in that order.  Your total 
string can
  	  be a maximum of 64 characters.

+config COMMAND_LINE_MAX_SIZE
+	int "Maximum kernel command-line size"
+	default 512
+	help
+	  This option allows you to specify maximum kernel 
command-line
+	  for kernel to handle.
+
  config SWAP
  	bool "Support for paging of anonymous memory (swap)"
  	depends on MMU

Re: [PATCH 1/1] 2.6.14-rc3 x86: COMMAND_LINE_SIZE

[Andi Kleen]

Alon Bar-Lev <alon.barlev@gmail.com> writes:
> 
> +config COMMAND_LINE_MAX_SIZE
> +	int "Maximum kernel command-line size"
> +	default 512
> +	help
> +	  This option allows you to specify maximum kernel command-line
> +	  for kernel to handle.

I think making that a config is a really bad idea. What happens
when the user specifies a very large value. Or a very small one?
There are subtle dependencies with the boot loader, so this is
mostly a lie anyways.  And it doesn't really safe enough memory to 
bother with a CONFIG.

Also the last time I tried to increase this all kind of systems
with old bootloaders exploded (e.g. lilo on systems with large EDID
information - search the archives). Have these issues been resolved now? 
If yes then I would suggest to just double the default.
If not it cannot be changed anyways.

-Andi

Re: [PATCH 1/1] 2.6.14-rc3 x86: COMMAND_LINE_SIZE

[Alon Bar-Lev]

Andi Kleen wrote:
> Alon Bar-Lev <alon.barlev@gmail.com> writes:
> 
>>+config COMMAND_LINE_MAX_SIZE
>>+	int "Maximum kernel command-line size"
>>+	default 512
>>+	help
>>+	  This option allows you to specify maximum kernel command-line
>>+	  for kernel to handle.
> 
> 
> I think making that a config is a really bad idea. What happens
> when the user specifies a very large value. Or a very small one?
> There are subtle dependencies with the boot loader, so this is
> mostly a lie anyways.  And it doesn't really safe enough memory to 
> bother with a CONFIG.

I don't understand this dependency. The cmd_line_ptr is a 
null terminated string which set by the boot loader.
The kernel reads this string until the null or 
COMMAND_LINE_MAX_SIZE.
If the user specified too large buffer or too small buffer 
it won't reflect the boot loader since it sets the maximum 
sizeof the buffer, and the kernel truncates it.

> Also the last time I tried to increase this all kind of systems
> with old bootloaders exploded (e.g. lilo on systems with large EDID
> information - search the archives). Have these issues been resolved now? 
> If yes then I would suggest to just double the default.
> If not it cannot be changed anyways.

I've looked at the sources of lilo and grub, both truncate 
the command line to 256 into the old protocol and set the 
cmd_line_ptr to point to the same place.

This change will no affect current implementation of the 
bootloader, but will allow them to change the code to set 
the cmd_line_ptr to the full command line.

I think that the maximum size should be set to 1024, but 
since the kernel allocates a static buffer, users may wish 
to optimize it. So I think that a configuration option is 
the right place.

Best Regards,
Alon Bar-Lev.

Re: [PATCH 1/1] 2.6.14-rc3 x86: COMMAND_LINE_SIZE

[Andi Kleen]

On Tuesday 11 October 2005 21:24, Alon Bar-Lev wrote:

> I don't understand this dependency. The cmd_line_ptr is a
> null terminated string which set by the boot loader.

Yes and limited by it and the boot protocol. And changing that CONFIG
wont' change that. IMHO this config is highly misleading.

> I think that the maximum size should be set to 1024, but
> since the kernel allocates a static buffer, users may wish
> to optimize it. So I think that a configuration option is
> the right place.

It's a bad idea to have a CONFIG for every buffer. If we go down this way
this way we end up with a unconfigurable kernel at some point with
hundreds of obscure parameters. Just increase it if there is a need for it.
If you're really worried about memory consumption you can
make the big buffer __initdata and copy it to a newly allocated buffer of the 
right size.

-Andi

Re: [PATCH 1/1] 2.6.14-rc3 x86: COMMAND_LINE_SIZE

[Alon Bar-Lev]

Andi Kleen wrote:
> 
> It's a bad idea to have a CONFIG for every buffer. If we go down this way
> this way we end up with a unconfigurable kernel at some point with
> hundreds of obscure parameters. Just increase it if there is a need for it.
> If you're really worried about memory consumption you can
> make the big buffer __initdata and copy it to a newly allocated buffer of the 
> right size.

OK... So I think 1024 bytes should be used... Does it sound OK?

But I still think that the documentation should not specify 
a fixed size, so that boot loaders will pass the full 
command line to the kernel.

Best Regards,
Alon Bar-Lev.

Re: [PATCH 1/1] 2.6.14-rc3 x86: COMMAND_LINE_SIZE

[Georg Lippold]

Alon Bar-Lev wrote:
> OK... So I think 1024 bytes should be used... Does it sound OK?

So, it boils down to using my previously posted patch?

> But I still think that the documentation should not specify a fixed
> size, so that boot loaders will pass the full command line to the kernel.

In my patch, it states:

"a boot loader may allow
 a longer command line to be passed to permit future kernels to extend
 this limit."

(as always in Documentation/i386/boot.txt)

Greetings,

Georg

Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Coywolf Qi Hunt]

On 9/7/05, H. Peter Anvin <hpa@zytor.com> wrote:
> Alon Bar-Lev wrote:
> >
> > Hello Peter, I've written a reply before but got no response...
> >
> > The idea of putting arguments in initramfs is not practical, since the
> > whole idea is to have the same image of system and affecting its
> > behavior using the boot loader...
> >
>
> No, you're wrong.  The boot loader can synthesize an initramfs.
>
> > I would like to push forward the idea to extend the command-line size...
> >
> > All we need for start is an updated version of the "THE LINUX/I386 BOOT
> > PROTOCOL" document that states that in the 2.02+  protocol the boot
> > loader should set cmd_line_ptr to a pointer to a null terminated string
> > without any size restriction, specifying that the kernel will read as
> > much as it can.
>
> Already pushed to Andrew.  I will follow it up with a patch to extend
> the command line, at least to 512.
>
> > After I get this update, I will try to work with GRUB and LILO so that
> > they will fix their implementation. Currently they claim that they
> > understand that they should truncate the string to 256.
> >
> > After that I will provide my simple  patch for setting the maximum size
> > the kernel allocates in the configuration.
> >
> > BTW: Do you know why the COMMAND_LINE_SIZE constant is located in two
> > separate include files?
>
> No, I don't.  It could be because one is included from assembly code in
> the i386 architecture.


The kernel uses the setup.h COMMAND_LINE_SIZE for both assembly and C
code. COMMAND_LINE_SIZE in param.h is only for bootloader IMHO.
--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/

Re: THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[H. Peter Anvin]

Coywolf Qi Hunt wrote:
> The kernel uses the setup.h COMMAND_LINE_SIZE for both assembly and C
> code. COMMAND_LINE_SIZE in param.h is only for bootloader IMHO.

Shouldn't really be there at all, then.

	-hpa