From: "H. Peter Anvin" <hpa@zytor.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] Gujin graphical bootloader 0.4
Date: Tue, 14 Aug 2001 09:42:55 -0700 [thread overview]
Message-ID: <3B79550F.4030800@zytor.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0108060228220.10664-100000@hp.masroudeau.com> <9kuid8$q57$1@cesium.transmeta.com> <m1n157rrpk.fsf@frodo.biederman.org> <9l2p9e$89h$1@cesium.transmeta.com> <m166brqeyc.fsf@frodo.biederman.org>
Eric W. Biederman wrote:
>
>>From your reaction I'm not explaining myself well. And since I'm
> working with a work in progress that isn't too much of a suprise.
>
> The basic rule is that nothing that can be queried from the hardware
> directly should be passed to the kernel. However we do need to have
> an interface to describe the hardware that we can't do a
> PCI/ISAPNP/USB/etc bus scan to get. To a certain extent the
> information is optional because sometimes we cannot get it. But if we
> can it is good to have.
>
> That is all I intend to pass to the linux kernel besides a command
> line the unprobeable hardware details. If something becomes probeable
> in the future that wasn't in the past, I'd spec it as optional to pass
> that information.
>
> For the kernel loaders I'd definentily have a standard probe routine
> that would query the traditional BIOS, and then package the results in
> the format I'm suggesting. Because of working around BUGS sometimes
> you need extra information that gets lost in translation, so I'm not
> 100% certain that is the best way to go. However it is possible to
> turn things on their heads and share the same code between multiple
> operating systems at which point it makes real sense to move that code
> into a bootloader. This is one of those questions worth looking very
> closely at.
>
The point is that this belongs in the kernel image, so that it can be
evolved, not in the boot loaders, where it becomes static. These kinds
of things will in practice change too quickly to be frozen into boot
loaders.
It's still a bad idea.
-hpa
next prev parent reply other threads:[~2001-08-14 18:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-06 10:15 [ANNOUNCE] Gujin graphical bootloader 0.4 Etienne Lorrain
2001-08-09 11:26 ` Matthias Andree
2001-08-09 13:38 ` Etienne Lorrain
2001-08-09 17:48 ` H. Peter Anvin
2001-08-11 7:17 ` Eric W. Biederman
2001-08-11 8:10 ` H. Peter Anvin
2001-08-14 7:27 ` Eric W. Biederman
2001-08-14 16:42 ` H. Peter Anvin [this message]
2001-08-15 16:40 ` Eric W. Biederman
-- strict thread matches above, loose matches on Subject: below --
2001-08-10 12:24 Etienne Lorrain
[not found] <fa.mdu6dgv.m10d9i@ifi.uio.no>
2001-08-10 13:02 ` Giacomo Catenazzi
2001-08-10 14:06 ` Etienne Lorrain
2001-08-13 12:05 Etienne Lorrain
2001-08-13 14:29 ` Keith Owens
2001-08-14 7:36 ` Eric W. Biederman
2001-08-14 7:53 ` Eric W. Biederman
2001-08-14 11:06 ` Etienne Lorrain
2001-08-14 15:46 ` Eric W. Biederman
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=3B79550F.4030800@zytor.com \
--to=hpa@zytor.com \
--cc=ebiederm@xmission.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox