From: ebiederm@xmission.com (Eric W. Biederman)
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-kernel@vger.kernel.org
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 23:31:08 -0700 [thread overview]
Message-ID: <m1r8pqv1w3.fsf@frodo.biederman.org> (raw)
In-Reply-To: <200112181605.KAA00820@tomcat.admin.navo.hpc.mil> <m18zbzwp34.fsf@frodo.biederman.org> <3C205FBC.60307@zytor.com> <m1zo4fursh.fsf@frodo.biederman.org> <9vrlef$mat$1@cesium.transmeta.com>
In-Reply-To: <9vrlef$mat$1@cesium.transmeta.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Followup to: <m1zo4fursh.fsf@frodo.biederman.org>
> By author: ebiederm@xmission.com (Eric W. Biederman)
> In newsgroup: linux.dev.kernel
> >
> > Which just goes to show what a fragile firmware design it is, to have
> > firmware callbacks doing device I/O. I think the whole approach of
> > having firmware callbacks is fundamentally flawed but I'll do my best
> > to keep it working, for those things that care. If it works over 50%
> > of the time I'm happy...
> >
>
> NAK. You can make it perfectly robust thankyouverymuch, as long as
> you don't try to *mix* firmware and poking directly at the
> hardware... this is a classic "who owns what" class problem.
I agree that I could keep it working as well as it ever would. Not
that x86 firmware or any software is ever perfectly working.
At this point in time I live in a world where 99+% of the time the
hardware is owned by the operating system, and the firmware is just
there to get the operating system loaded, and to hold details about
the motherboard that the operating system can not find out by probing
the hardware.
For the cases I find important I get better reliability and
portability by never involving the firmware at all. If there is a
problem with a driver I can fix it. If I want to switch cpus I can.
Admittedly the cost for native drivers is high, but if I don't have to
pay that cost twice and can actually reuse my OS drivers. It isn't a
price I mind paying.
I care about not trashing the firmware so a newer probe routine can
find out more precisely or robustly what is on a motherboard. Having
a reasonable chance that the firmware can also still drive the
hardware is a plus.
I criticize firmware designers, not to attack anyones dependence on
the firmware. But more to make certain I never implement anything
like that.
I don't think I have seen a firmware design where someone has designed
it with the assumption that humans mess up. Instead every firmware
interface I have seen seems to be designed by asking how can I include
every possible desirable feature. Since it is painful to fix or
replace firmware this is a real issue.
I have seen alpha firmware getting confused when the operating system
uses the hardware, when rebooting on the alpha. Which is why I am
sensitive to it.
Eric
next prev parent reply other threads:[~2001-12-20 6:51 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
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 [this message]
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=m1r8pqv1w3.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox