From: ebiederm@xmission.com (Eric W. Biederman)
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: "Erik A. Hendriks" <hendriks@lanl.gov>,
Andrew Morton <akpm@zip.com.au>,
linux-kernel@vger.kernel.org,
Werner Almesberger <wa@almesberger.net>
Subject: Re: [RFC] x86 ELF bootable kernels/Linux booting Linux/LinuxBIOS
Date: 02 Feb 2002 16:02:28 -0700 [thread overview]
Message-ID: <m1k7tv8p2z.fsf@frodo.biederman.org> (raw)
In-Reply-To: <m1elk7d37d.fsf@frodo.biederman.org> <3C586355.A396525B@zip.com.au> <m1zo2vb5rt.fsf@frodo.biederman.org> <3C58B078.3070803@zytor.com> <m1vgdjb0x0.fsf@frodo.biederman.org> <3C58CAE0.4040102@zytor.com> <20020131103516.I26855@lanl.gov> <m1elk6t7no.fsf@frodo.biederman.org> <3C59DB56.2070004@zytor.com> <m1r8o5a80f.fsf@frodo.biederman.org> <3C5A5F25.3090101@zytor.com> <m1hep19pje.fsf@frodo.biederman.org> <3C5ADDD1.6000608@zytor.com> <m1665fame3.fsf@frodo.biederman.org> <3C5C54D2.2030700@zytor.com>
In-Reply-To: <3C5C54D2.2030700@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> The flaw in your understanding comes in when you want to run maintenance on a
> system, reinstall it, install a system for which you don't have drivers, etc.
> Otherwise you're basically requiring the memory on the target system to contain
> every driver that could possibly exist, not just today but in the future.
It does seem to be a requirement to contain every driver for at least
one class of devices in ram. So it looks like Firmware to support
ease of administration needs to support loading both user-space
programs, and kernel-space programs. At a first approximation I
agree, but I need to think on this some more.
For the acceptance of a Linux booting Linux patch this case isn't a
problem because it is only an enabler, that is good news.
For the firmware case with LinuxBIOS that is an element I had not
thought of. And it is a problem because it hinders automation. The
only place a firm line has been drawn so far is where LinuxBIOS
stops, and where the in firmware bootloader begins. Embedded systems
don't in general need or want the flexibility a full general purpose
firmware provides so can be ignored, but for general purpose systems
this is an issue. The original design called for the using the Linux
kernel (in which case a trivial answer would be forthcoming) but in
many instances you cannot compile the Linux kernel small enough to be
useful.
It can be argued that general purpose systems have enough ram that
putting drivers for all mass produced devices in ram is possible, and
practical. But that is a cop out.
Eric
next prev parent reply other threads:[~2002-02-02 23:06 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-30 19:54 [RFC] x86 ELF bootable kernels/Linux booting Linux/LinuxBIOS Eric W. Biederman
2002-01-30 21:19 ` Andrew Morton
2002-01-30 23:52 ` Keith Owens
2002-01-31 2:42 ` Eric W. Biederman
2002-01-31 2:48 ` H. Peter Anvin
2002-01-31 4:27 ` Eric W. Biederman
2002-01-31 4:41 ` H. Peter Anvin
2002-01-31 5:15 ` Eric W. Biederman
2002-01-31 5:59 ` H. Peter Anvin
[not found] ` <m1n0yvaucy.fsf@frodo.biederman.org>
2002-01-31 17:57 ` H. Peter Anvin
2002-01-31 22:34 ` Eric W. Biederman
2002-01-31 22:52 ` H. Peter Anvin
2002-02-01 7:52 ` Eric W. Biederman
2002-01-31 17:35 ` Erik A. Hendriks
2002-01-31 23:36 ` Eric W. Biederman
2002-02-01 0:03 ` H. Peter Anvin
2002-02-01 9:03 ` Eric W. Biederman
2002-02-01 9:25 ` H. Peter Anvin
2002-02-01 15:42 ` Eric W. Biederman
2002-02-01 18:26 ` H. Peter Anvin
2002-02-02 16:17 ` Eric W. Biederman
2002-02-02 21:06 ` H. Peter Anvin
2002-02-02 23:02 ` Eric W. Biederman [this message]
2002-02-03 1:56 ` H. Peter Anvin
2002-02-03 18:43 ` Eric W. Biederman
2002-02-03 19:39 ` H. Peter Anvin
2002-02-03 22:18 ` Rob Landley
2002-02-03 22:24 ` H. Peter Anvin
2002-02-03 22:59 ` Rob Landley
2002-02-03 23:01 ` H. Peter Anvin
2002-02-03 23:47 ` Rob Landley
2002-02-04 1:34 ` H. Peter Anvin
2002-02-04 9:53 ` Marco Colombo
2002-02-04 16:19 ` H. Peter Anvin
2002-02-04 19:55 ` Eric W. Biederman
2002-02-04 20:51 ` Alan Cox
2002-02-04 20:40 ` H. Peter Anvin
2002-02-03 19:48 ` H. Peter Anvin
2002-02-04 20:16 ` Eric W. Biederman
2002-02-04 4:29 ` Keith Owens
2002-02-04 20:01 ` Eric W. Biederman
2002-02-04 12:49 ` Werner Almesberger
2002-02-04 16:26 ` H. Peter Anvin
2002-02-04 19:45 ` Eric W. Biederman
2002-02-04 21:02 ` Werner Almesberger
2002-02-04 21:08 ` H. Peter Anvin
2002-02-05 7:45 ` Eric W. Biederman
2002-02-01 0:46 ` Keith Owens
2002-01-31 3:03 ` Keith Owens
2002-02-01 7:22 ` Greg KH
2002-01-30 21:32 ` H. Peter Anvin
2002-01-31 2:31 ` 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=m1k7tv8p2z.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=akpm@zip.com.au \
--cc=hendriks@lanl.gov \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=wa@almesberger.net \
/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