From: "H. Peter Anvin" <hpa@zytor.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: torvalds@transmeta.com, marcelo@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Linux/i386 boot protocol version 2.03
Date: Sun, 09 Dec 2001 15:13:37 -0800 [thread overview]
Message-ID: <3C13F021.3080307@zytor.com> (raw)
In-Reply-To: <200112090922.BAA11252@tazenda.transmeta.com> <m17krww8ky.fsf@frodo.biederman.org> <3C13DD48.3070206@zytor.com> <m11yi4vxvb.fsf@frodo.biederman.org>
Eric W. Biederman wrote:
>
>>(3) Contradicts (1) as well as issues with older kernels. Keep in mind what
>>happens if you violate this limit: the bootloader should be loading the initrd
>>as high as possible
>>
>
> Hmm. Bootloaders have had lots of restrictions on getting up high.
> Plus in some real sense it make sense to pack the two as close
> together as possible. For 2.5.x and Al Viro's initfs work I'd like
> to do that.
>
> If you load your ramdisk at the same location every time, after
> a point you have fewer surprises, and potentially a simpler bootloader.
>
NO, PLEASE PLEASE PLEASE DON'T DO THAT!!!!
Not only would it royally fuck over people with small amounts of RAM, it
would also really fuck over people who use the Linux boot protocol for
other purposes, which is getting quite common.
>
>>, so the only difference is if you get the error message from
>>
>>the boot loader or from the kernel later. If you're going to export a limit,
>>you better make sure it's right; "8MB except on low memory configurations"
>>doesn't cut it. It's exactly on those low memory configurations that this limit
>>
>>matters *at all*.
>>
>
> 8MB is the safe limit. The only worry some case right now is the
> bootmem allocator with a darn huge bitmap. It is allocated
> dynamically, and it is extremely hard to predict where that will be
> except in the initial page tables 8MB in size. If the ugly bitmap
> is allocated elsewhere the kernel can't use it.
>
"Safe limit" isn't applicable here. It either works or it doesn't.
You're breaking systems which it would otherwise work on, which is not
acceptable.
> So if we are going to fix the fragility please let's handle both ends.
> Then it will be o.k. to put the ramdisk where ever the kernel says
> it is safe. And we can stop this guessing and breaking game.
You're giving the boot loader options that are really inappropriate.
All that will do is result in more variance between boot loaders and the
resulting bugs that will bite some bootloaders and not others.
Allowing unneeded options in protocols is a source of bugs. You seem to
think this is a good idea, it's not.
-hpa
next prev parent reply other threads:[~2001-12-09 23:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-09 9:22 Linux/i386 boot protocol version 2.03 H. Peter Anvin
2001-12-09 18:29 ` Eric W. Biederman
2001-12-09 21:53 ` H. Peter Anvin
2001-12-09 22:20 ` Eric W. Biederman
2001-12-09 23:13 ` H. Peter Anvin [this message]
2001-12-09 23:18 ` Eric W. Biederman
2001-12-09 21:56 ` 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=3C13F021.3080307@zytor.com \
--to=hpa@zytor.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@kernel.org \
--cc=torvalds@transmeta.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox