Eric Seppanen <[EMAIL PROTECTED]> writes:
> On Mon, Feb 26, 2001 at 03:31:11PM -0700, Ronald G Minnich wrote:
> > On Mon, 26 Feb 2001 [EMAIL PROTECTED] wrote:
> >
> > > So the question becomes: How strongly do we believe that "if the
> > > kernel can the kernel must"? How much of hardwaremain.c should be
> > > moved into the kernel?
> >
> > that's a question for the list. I would like to hear some other comments.
>
> In a general sense, whenever I've disagreed with the "if the kernel
> can..." guideline, it's been because I believe more strongly in the
> benefits of economy of scale.
>
> That means that I love using embedded x86 linux because I get the benefit
> of millions of person-hours and billions of machine-hours using the same
> stuff as me. When questions arise such as "should linuxbios configure the
> PCI bus, even if the kernel can handle it?" I say yes, not because it's
> technically better but because that's how all those millions of desktop
> PCs are behaving. So I prefer that linuxbios simulate as closely as
> possible the state a PC would be in as the kernel is launched under
> factory-BIOS conditions.
This does sound reasonable. There are a few interesting things here though.
1) Linux relies on the BIOS more than Windows does.
2) If you can get reliable kernel driver that always sets up hardware it
doesn't matter who sets it up.
3) From the ARM and other embedded probjects the common way to use drivers
like the framebuffer are from linux.
>
> Obviously there's exceptions- 16-bit real mode is obviously stupid and
> useless. Most BIOS conventions are stupid and deserve to be tossed. 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.
A recent example sits in my memory. I was helping someone with their laptop,
get a serial link up to an embedded PDA running linux. The problem
was that the BIOS had disabled the serial port and linux couldn't see
it. However if you booted the laptop into windows the serial port
worked. I think whenever linux trusts the BIOS vendors more than
windows does we have issues.
Eric
