Eric Seppanen <[EMAIL PROTECTED]> writes:
> 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?
Most of the stuff I've seen is a one time config thing to put the
hardware in a know state for a know piece of hardware, not easy to
break.
Plus the issue comes up on other embedded platforms, besides
linuxBIOS.
In practice what this means is I managed to bring my ds10 including the
framebuffer driver on 2.4 with only needing to tweak the
real-time-clock driver, and the i8259 legacy interrupt controller
driver.
> 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).
Sounds reasonable. I'll think how this could be done. Linux
rebooting straight from linux will bring some of this up.
> 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.
Or the mainstream kernel testers. This sounds like a good idea.
Note booting an x86 and saying you are a pnp os. Does this for most
of the hardware anyway. Hardware with onboard ROM's are the only
exceptions.
As for linuxBIOS getting widespread I think it has a real chance,
especially with the work for cluster to get it up on the latest and
greatest motherboards with commodity parts.
Eric
