From: ebiederm@xmission.com (Eric W. Biederman)
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] Gujin graphical bootloader 0.4
Date: 15 Aug 2001 10:40:16 -0600 [thread overview]
Message-ID: <m1ofphp98v.fsf@frodo.biederman.org> (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> <3B79550F.4030800@zytor.com>
In-Reply-To: <3B79550F.4030800@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> 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.
In principle I agree. But until I have thought out all of the angles
I'll play with just about every idea.
I will say though that having a 32bit entry point in a bootloader is
fully reasonable as, if you are doing anything more than zImage the
bootloader needs to switch into protected mode anyway. However having
a the ability to switch back into realmode to do BIOS calls is also
reasonable. The interesting case there is loadlin.
But I fully agree that bootloaders should be as simple as possible
with respect to the kernel. But I also have a major issue with
the fact that rdev only works on x86. And even with linuxBIOS around
it would be nice to compile a kernel that is x86-generic. That is one
of the neater ideas of the alpha port. I know on the ppc port it
splits up per bootloader. I don't have any problems with compiling
for a specific environment but I don't want to make it mandatory.
Eric
next prev parent reply other threads:[~2001-08-15 16:47 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
2001-08-15 16:40 ` Eric W. Biederman [this message]
-- 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=m1ofphp98v.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=hpa@zytor.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 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.