Eric Seppanen <[EMAIL PROTECTED]> writes:
> On Wed, Dec 13, 2000 at 08:34:52PM -0700, Ronald G Minnich wrote:
> > On Wed, 13 Dec 2000, Levi Khatskevitch wrote:
> >
> > > > The idea is: have linuxbios copied to ram before the kernel is started,
> > > > then teach the linux kernel to recognize linuxbios as though it were a
> > > > sort of kernel-module, and make the linuxbios namespace and functions
> > > > available from within the kernel.
> >
> > I've been looking at the acpi support in 2.4. I no longer see a need for
> > this. Plus, I keep going back to the main idea: linuxbios should not do
> > much. Linux should. Otherwise we're going to end up duplicating linux
> > capabilities, badly.
>
> I don't know a thing about ACPI, so I guess I can't comment intelligently
> on that.
Same here going into research mode after lunch.
> But there are things that the linux kernel does badly, and among those
> things are areas where board-specific knowledge is needed, making simple
> tasks complicated. For embedded systems it's easy to end up in a
> situation where the kernel has to get patched left and right to accomodate
> unique hardware, and in this case it's much easier to modify linuxbios to
> accomodate the hardware, rather than let linux try to duplicate BIOS
> functionality, badly. :)
Hmm. I'm not too certain about that one. If the kernel needs to be
heavily patched, and not just new drivers added. It seems in need of
some redisgn. Which would benefit everybody.
> I guess I can understand how you cluster guys can see it differently:
> you're using commodity hardware that's well supported directly by the
> kernel. When you have embedded hardware that's subtly different from
> everybody else's hardware it's a lot simpler to keep your hardware-
> specific code in one place.
Which is why we like to do things in the kernel. That is the repository
of hardware information.
> For me, linuxbios does two things: board-specific hardware config and
> generic kernel-booting. If linuxbios has to learn how to configure a
> piece of hardware (let's say chipset setup) it seems like a waste of
> energy to teach the linux kernel how to do the same thing (especially
> because the linux kernel would need to know how to do it for many
> different boards, while linuxbios is built for one particular board).
Where I see the line is that if something needs to be done dynamically
at run time linux should know how to do it. If it is something you can
get away with doing it once and forgetting the it can go into linuxbios.
One of the things it looks like we will be able to take out of linuxBIOS,
in the near future is PCI setup. 2.4.0 seems increasing able to do
PCI setup. Not because it is a one time thing, but more because it has
to tackle PCI setup to handle hot plug of PCI devices, in laptops.
> Before anybody really freaks out, I'm not seriously suggesting linuxbios
> be changed in any way.
The rest of us are :). We are all still learning how to make this work.
> But I don't think that kernel->bios calls are
> always an absolutely _horrible_ idea, and shouldn't be rejected simply
> because linux doesn't do it that way today. Linux hates the bios because
> the bios is 16-bit, and proprietary, and often broken. A 32-bit, open,
> working bios is much friendlier.
Where I come in is I see that a lot of sucky code is because of tight
deadline pressure. I don't see an open source bios being any better
than a proprietary bios in that respect. And although it is now
possible to update firmware it is still something you should never
_need_ to do. I much prefer updating a kernel on a disk somewhere
than something in flash.
Embedded special purpose devices come out a little better in this
regard, as their total set of features are fixed, and can be tested
thoroughly. But general purpose devices can be a real pain unless
you severly limit what you can do.
Eric
