Re: [PATCH] Add support for longer kernel command lines (i586, x86_64, IA64)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Tue, Mar 06, 2007 at 10:24:56AM +0100, Bernhard Walle wrote:
> Hello,
> 
> * Vivek Goyal <vgoyal@xxxxxxxxxx> [2007-03-06 05:15]:
> > On Tue, Mar 06, 2007 at 09:42:04AM +0530, Vivek Goyal wrote:
> > > On Mon, Mar 05, 2007 at 11:34:33PM +0100, Bernhard Walle wrote:
> > > > This patch increases the kernel command line size for x86_64 and i386
> > > > to 2048 characters. This is necessary because with kernel 2.6.21
> > > > and newer, the kernel command line size has increased and kexec needs
> > > > lot of command line space, so this solves some "command line overflow"
> > > > problems.
> > > > 
> > > > To be able to warn users running older kernels that the command line
> > > > is too long (and don't wait that the kernel truncates it), the
> > > > patch tries to get the kernel command line length from the kernel
> > > > image that is loaded if possible by checking the length of the
> > > > static array that holds the kernel command line when booting.
> > > 
> > > It does not work for compressed images (bzImage). So kexing older bzImages
> > > will never give you a warning message.
> > > 
> > > Secondly, I think creating dependencies on kernel symbols is bad. Tomorrow
> > > if kernel code changes, we are broken. The problem "crash" faces so often.
> > > So we should create a well defined interface which can remain constant 
> > > even if kernel code changes.
> > > 
> > > I personally think either there should be a way to specify command line
> > > length supported in the image format (bzImage) or we should export it to 
> > > user space, lets say through /proc/ interface. 
> > > 
> > > Specifying max cmdline lenght in bzImage header helps because any bootloader
> > > then take a clue and warn user about excessive command line length.
> > > 
> > > Otherwise we can export something like /proc/max_cmdline_len on the lines
> > > of /proc/cmdline.
> > 
> > Thinking more about it. I think exporting it through /proc/ will work better.
> > Extending bzImage format will help only bzImage but problem for ELF vmlniux
> > will still persist, until we decide to append an ELF note to vmlinux.
> 
> A /proc interface is a bit useless IMO. It tells you about the command
> line size of the running kernel, but not about the command line size
> of the kernel you try to load.
> 

Oh.. You are right. Somehow it slipped out of my mind that kernel being
kexec'd might not have any relevance to the running kernel.

> My patch about changing the header in x86_64/i386 was not applied
> (http://marc.theaimsgroup.com/?l=linux-kernel&m=117138549731788&w=2)
> although I got positive repsonse from the maintanier (H. Peter Anvin),
> but he was travelling at that time ...
> 

I think above patch then makes sense. How about posting it again and
try to get it in. May be this time Peter will like it. To me it makes
sense. Kernel image should let the bootloader know regarding what 
cmdline size does it support.

> I'm also not very lucky about the solution to get the size from the
> ELF symbol table. Maybe a ELF not plus getting the bzImage header
> applied would be the best compromise. Or do we really want to trust
> that the kernel that runs has the same command line size as the kernel
> that is kexec'd to?

We can't assume that running kernel and kernel being kexec'd to are same.
How about adding an PT_NOTE ELF note to vmlinux image exporting what's the
size of supported command line? This probably will meet some resistance but
its worth giving it a try. I consider this to be a better option then trying
to parse the symbol table and run into maintenace issues later.

Thanks
Vivek
_______________________________________________
fastboot mailing list
fastboot@xxxxxxxxxxxxxx
https://lists.osdl.org/mailman/listinfo/fastboot


[Netdev]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Photo]     [Yosemite]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]     [Linux Media]     [Linux Resources]

Powered by Linux