On Mon, Feb 26, 2001 at 04:58:29PM -0700, Eric W. Biederman wrote:
> > ... But
> > when linuxbios boots a machine that's set up fundamentally different than
> > most PCs, I get scared because we're setting out on a path that is
> > different from the rest of the linux world. On this path bugs can only
> > be solved using the twenty or a hundred linuxbios project brains instead
> > of the thousands or millions of linux-using brains.
>
> Which is why I don't advocate taking out any code we have allready written
> (at least until a better way is proven), and why I will back down if the kernel
> developers are against it. However in a lot of situations I think the kernel
> depends upon the BIOS because of (duh I hadn't thought of that). And in those
> cases I would like to push linux in the direction of better hardware init.
The problem is that outside of people using linuxbios, that hardware init
code will never be used, never tested. It'll get broken during other
changes, and unless a significant number of kernel developers start using
linuxbios, it's a permanent drain on linuxbios developers to baby-sit the
kernel hardware init stuff. If that (pessimistic, I know) were true,
wouldn't it be easier in the long run to just drop the init code into
linuxbios?
Idea: Perhaps it would help if somebody wrote a kernel patch to
intentionally un-enable (??) as much hardware as possible. This would
site right in front of kernel init, and simulate a linuxbios-type setup
for mainstream kernel developers. It could be pitched to them as a tool
to test for broken BIOSes, too (which I bet they see a _lot_ and get
really tired of debugging).
Then, (assuming you could somehow convince at least some mainstream kernel
developers to actually use the patch regularly) any breakage of
hardware-init routines could be caught by the main kernel gurus.
Eric
