All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Alon Bar-Lev <alon.barlev@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Barry K. Nathan" <barryn@pobox.com>,
	Adrian Bunk <bunk@fs.tum.de>
Subject: Re: [PATCH][TAKE 3] THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit
Date: Fri, 14 Apr 2006 12:04:27 -0700	[thread overview]
Message-ID: <443FF23B.8020209@zytor.com> (raw)
In-Reply-To: <443FF181.6000004@gmail.com>

Alon Bar-Lev wrote:
> H. Peter Anvin wrote:
>>
>> Well, obviously, since apparently LILO doesn't properly null-terminate 
>> long command line.
>>
>> Thinking about it a bit, the way to deal with the LILO problem is 
>> probably to actually *usw* the boot loader ID byte we've had in there 
>> since the 2.00 protocol.  In other words, if the boot loader ID is 
>> 0x1X where X <= current version (I don't know how LILO manages this 
>> ID) then truncate the command line to 255 bytes; when this is fixed in 
>> LILO then LILO gets to bump its boot loader ID version number.
>>
>>     -hpa
> 
> I don't understand...
> 
> If LILO worked until now, it should continue to work after applying this 
> patch, since nothing was changed from its perspective. It will continue 
> to provide 255 characters + null command line, so even if you have 1024 
> max command-line, then you will still receive truncated to 255 chars.
> 

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.

	-hpa

  reply	other threads:[~2006-04-14 19:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-13 23:54 [PATCH][TAKE 3] THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit Alon Bar-Lev
2006-04-14  0:38 ` Joshua Hudson
2006-04-14 17:53 ` H. Peter Anvin
2006-04-14 18:09   ` Alon Bar-Lev
2006-04-14 18:46     ` H. Peter Anvin
2006-04-14 19:01       ` Alon Bar-Lev
2006-04-14 19:04         ` H. Peter Anvin [this message]
2006-04-14 19:05         ` H. Peter Anvin

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=443FF23B.8020209@zytor.com \
    --to=hpa@zytor.com \
    --cc=alon.barlev@gmail.com \
    --cc=barryn@pobox.com \
    --cc=bunk@fs.tum.de \
    --cc=linux-kernel@vger.kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.