limit to the length of args passed to kernel

limit to the length of args passed to kernel

[Roberto De Leo]

Hi,
I recently found out the you can't pass too many args to the kernel 
through the LILO "append"
option. Actually I passed the args through the similar "append" option 
of the SysLinux package
(http://syslinux.zytor.com/) but on their ML I have been told it is 
equivalent to LILO's one and
that there is a 256 characters limit for passing args at boot time to 
the kernel.

My question is: is this really a kernel limit or I misunderstood? if it 
is a kernel limit,
is there any way to bypass it?

It would be very useful for a package I am developing: it is a micro 
linux distro (the initrd.gz
is ~4MB) containing basically only a kernel and what you need to play a 
movie through the FB.
The kernel (2.4.19) has been compiled with support for all possible FB 
drivers, but for several
reasons it would be nice to have two booting options: one containing the 
initialization for all
possible FB and one turning all of them off except the vesa FB.
Unfortunately though there are so many FB driverd that to turn them all 
off it takes much more
than 256 chars!

Any help would be greatly appreciated.
Please CC me any answer to deleo@unica.it, I'm not subscrribed to the ML.
Thanks,
 Roberto De Leo

Re: limit to the length of args passed to kernel

[Randy.Dunlap]

I haven't seen any other replies to this on lkml, so...

On Sat, 5 Oct 2002, Roberto De Leo wrote:

| Hi,
| I recently found out the you can't pass too many args to the kernel
| through the LILO "append"
| option. Actually I passed the args through the similar "append" option
| of the SysLinux package
| (http://syslinux.zytor.com/) but on their ML I have been told it is
| equivalent to LILO's one and
| that there is a 256 characters limit for passing args at boot time to
| the kernel.

According to that mailing list, Peter Anvin has already confirmed
this.

| My question is: is this really a kernel limit or I misunderstood? if it
| is a kernel limit, is there any way to bypass it?

I didn't see any mention of what type of hardware you are using,
but COMMAND_LINE_SIZE is a #define in the Linux kernel.
You could change that, but that wouldn't "fix it."
The boot protocol interface (from LILO or SysLinux etc. to the
kernel) must also be changed for this to work.

See linux/Documentation/i386/boot.txt for that interface definition.

BTW, some other CPU architectures #define larger command line
sizes, but then they don't use this same boot interface (I
guess).

| It would be very useful for a package I am developing: it is a micro
| linux distro (the initrd.gz
| is ~4MB) containing basically only a kernel and what you need to play a
| movie through the FB.
| The kernel (2.4.19) has been compiled with support for all possible FB
| drivers, but for several
| reasons it would be nice to have two booting options: one containing the
| initialization for all
| possible FB and one turning all of them off except the vesa FB.
| Unfortunately though there are so many FB driverd that to turn them all
| off it takes much more than 256 chars!
|
| Any help would be greatly appreciated.
| Please CC me any answer to deleo@unica.it, I'm not subscrribed to the ML.

Good luck.

-- 
~Randy