From: ebiederm@xmission.com (Eric W. Biederman)
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>,
Christian Koenig <ChristianK.@t-online.de>,
"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>,
Otto Wyss <otto.wyss@bluewin.ch>,
Alexander Viro <viro@math.psu.edu>, antirez <antirez@invece.org>,
Andreas Dilger <adilger@turbolabs.com>,
"Grover, Andrew" <andrew.grover@intel.com>,
Craig Christophel <merlin@transgeek.com>
Subject: Re: Booting a modular kernel through a multiple streams file / Making Linux multiboot capable and grub loading kernel modules at boot time.
Date: 19 Dec 2001 02:12:31 -0700 [thread overview]
Message-ID: <m18zbzwp34.fsf@frodo.biederman.org> (raw)
In-Reply-To: <200112181605.KAA00820@tomcat.admin.navo.hpc.mil> <m1r8prwuv7.fsf@frodo.biederman.org> <3C204282.3000504@zytor.com> <m1itb3wsld.fsf@frodo.biederman.org> <3C2052C0.2010700@zytor.com>
In-Reply-To: <3C2052C0.2010700@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Eric W. Biederman wrote:
>
> > I have a personally dislike for using firmware calls to drive hardware
> > devices, so I won't be picking that up. But I am interested in what
> > it requires to not burn bridges. So I can make certain a linux kernel
> > loaded with a linux booting linux patch can requery the firmware.
> >
>
> > My impression is that the linux kernel already does the important
> > things by not smashing firmware reserved memory, (assuming you aren't
> > loaded with loadlin). So all that is required is to switch the idt
> > back to address 0, and switch the cpu back to 16bit real mode.
> > But if you know of other cases that need to be handled I would be
> > happy to hear about it.
> >
>
>
> Unfortunately that's not the case. The big issue is "who owns the interrupt
> controller", and "who owns the interrupts."
[snip]
> You can check out the BIOS extender I wrote for genesis at
> ftp://ftp.zytor.com/pub/linux/genesis/
Thanks. I've got genesis-1.10 now looking and digesting to see if you
have any unexpected tricks takes a little longer.
For my purposes I intend to fully disable the BIOS and then after I
have done all of my work, reenable the BIOS. Which should be a little
easier and have a slightly different set of issues.
>From the 10,000 foot level it looks like I am pretty safe already
except for those BIOS functions that drive the hardware. For those I
need to setup the legacy PIC back to it's default setting, and
possibly a few other hardware things. I wonder just how sensitive
the an x86 BIOS really is to changing those things...
For the most part I find it perfectly acceptable if I break all of the
firmware hardware drivers. As long as the information callbacks are
preserved. But preserver enough so I could load dos from linux would
be nice.
Eric
next prev parent reply other threads:[~2001-12-19 9:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-18 16:05 Booting a modular kernel through a multiple streams file / Making Linux multiboot capable and grub loading kernel modules at boot time Jesse Pollard
[not found] ` <m1r8prwuv7.fsf@frodo.biederman.org>
[not found] ` <3C204282.3000504@zytor.com>
[not found] ` <m1itb3wsld.fsf@frodo.biederman.org>
[not found] ` <3C2052C0.2010700@zytor.com>
2001-12-19 9:12 ` Eric W. Biederman [this message]
2001-12-19 9:37 ` H. Peter Anvin
2001-12-19 15:57 ` Eric W. Biederman
2001-12-20 3:20 ` H. Peter Anvin
2001-12-20 6:31 ` Eric W. Biederman
2001-12-20 6:57 ` H. Peter Anvin
2001-12-20 16:39 ` Eric W. Biederman
2001-12-20 18:35 ` H. Peter Anvin
2001-12-21 16:57 ` Eric W. Biederman
-- strict thread matches above, loose matches on Subject: below --
2001-12-17 22:10 Booting a modular kernel through a multiple streams file Grover, Andrew
2001-12-18 15:26 ` Booting a modular kernel through a multiple streams file / Making Linux multiboot capable and grub loading kernel modules at boot time Christian Koenig
2001-12-18 18:32 ` 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=m18zbzwp34.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc="ChristianK."@t-online.de \
--cc=adilger@turbolabs.com \
--cc=andrew.grover@intel.com \
--cc=antirez@invece.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=merlin@transgeek.com \
--cc=otto.wyss@bluewin.ch \
--cc=pollard@tomcat.admin.navo.hpc.mil \
--cc=viro@math.psu.edu \
/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