Current implementation allows the kernel to receive up to255 characters from the bootloader.

In current environment, the command-line is used in order tospecify many values, including suspend/resume, modulearguments, splash, initramfs and more.

255 characters are not enough anymore.

This is take 4 of this submission.

Take 4 (current), no reply of what is the problem in LILO.Can someone please reply Peter questions? I understand thatpeople don't want the new kernel config option... But fixingLILO should be more complex.

Take 3 - Back to menuconfig option, so it won'tbreak LILO (Although if it is broken because of this, itshould be fixed...).

Here are the comments from H. Peter Anvin:> Does anyone know the actual details of the LILO breakage?> If the problem is that LILO doesn't null-terminate the string when it's too long,> then we can deal with this automatically, without introducing compile-time options> (which were already once rejected.)> > If the problem is with LILO booting *old* kernels, then that's going to have to require> some LILO changes, and probably a boot revision bump.

Take 2 - Removed the menuconfig into a fixed 2048 size. Thispatch was rejected. This is what the 2.6.11-rc2 changeloghas to say about the matter:

> Revert "x86_64/i386: increase command line size" patch> It's a bootup dependancy, you can't just increase it> randomly, and it breaks booting with LILO.> Pointed out by Janos Farkas and Adrian Bunk.

Take 1 - Patch that allows command-line size to bedetermined in menuconfig. People did not want to see a newconfig option.

---

If any of you think that this should be applied for otherarchitectures, please reply.