LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Bernhard Walle <bwalle@suse.de>
To: Andrew Morton <akpm@osdl.org>, "H. Peter Anvin" <hpa@zytor.com>,
Alon Bar-Lev <alon.barlev@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@novell.com>,
Andreas Kleen <ak@suse.de>, Torsten Duwe <duwe@suse.de>
Subject: [PATCH] i386, x86_64: Change Boot Protocol to longer command lines
Date: Fri, 2 Feb 2007 11:07:51 +0100 [thread overview]
Message-ID: <20070202100751.GA29200@strauss.suse.de> (raw)
After the kernel can handle command lines with 2048 characters, the
documentation should be updated.
I think it would be better to increase the boot protocol version, just
to make it possible that kexec and bootloaders can determine the size
of the command line. The problem is that if we just increase the
length in kexec, it's not possible to determine if the user wants to
load an old kernel and warn him that the kernel truncates the command
line after 256 characters.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Acked-by: Torsten Duwe <duwe@suse.de>
---
Documentation/i386/boot.txt | 11 ++++++-----
arch/i386/boot/setup.S | 2 +-
2 files changed, 7 insertions(+), 6 deletions(-)
Index: b/Documentation/i386/boot.txt
===================================================================
--- a/Documentation/i386/boot.txt
+++ b/Documentation/i386/boot.txt
@@ -2,7 +2,7 @@
----------------------------
H. Peter Anvin <hpa@zytor.com>
- Last update 2007-01-26
+ Last update 2007-02-01
On the i386 platform, the Linux kernel uses a rather complicated boot
convention. This has evolved partially due to historical aspects, as
@@ -243,10 +243,11 @@ relevant to the boot loader itself, see
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
-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.
+2047 characters long, plus the final null. With protocol version
+2.05 and earlier, the maximum length was 255 characters. 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.
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
Index: b/arch/i386/boot/setup.S
===================================================================
--- a/arch/i386/boot/setup.S
+++ b/arch/i386/boot/setup.S
@@ -81,7 +81,7 @@ start:
# This is the setup header, and it must start at %cs:2 (old 0x9020:2)
.ascii "HdrS" # header signature
- .word 0x0205 # header version number (>= 0x0105)
+ .word 0x0206 # header version number (>= 0x0105)
# or else old loadlin-1.5 will fail)
realmode_swtch: .word 0, 0 # default_switch, SETUPSEG
start_sys_seg: .word SYSSEG
reply other threads:[~2007-02-02 10:23 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20070202100751.GA29200@strauss.suse.de \
--to=bwalle@suse.de \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=alon.barlev@gmail.com \
--cc=duwe@suse.de \
--cc=gregkh@novell.com \
--cc=hpa@zytor.com \
--subject='Re: [PATCH] i386, x86_64: Change Boot Protocol to longer command lines' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).