"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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:00:25 EST