> In message <Pine.HPP.3.91.980812151305.11627B-100000@gaia.ecs.csus.edu>,
> "Jon M
> . Taylor" writes:
> +-----
> | On Wed, 12 Aug 1998, Brandon S. Allbery KF8NH wrote:
> | > In message <m0z6d1t-000aNFC@the-village.bc.nu>, Alan Cox writes:
> | > | an argument against any specific setup btw - no doubt kernel code would
> | > | have some upset potential too)
> | > "Some"? Is wedging the console less preferable than wedging thwe entire
> | > system? I know where I can get NT4 in that case :-)
> | Suppose the sounds driver locks up and wedges your system that
> | way. Better put in in usersapce too. After all, you aare a lot better
> +--->8
>
> The sound driver doesn't map and copy big chunks of memory around. More to
> the point, compare the number of crashes from Alan's sound driver work to
> those during fbcon development.
Alan is a really, really good and knowledgeable coder. I'd expect
his work to come out of the gate being higher quality. And I am *quite*
familiar with the tasks that are expected of a video driver, having spent
the last three years writing video drivers and looking at video driver
code. Most of the bad stability rep that video drivers have picked up has
come from their being sloppily coded and/or not properly isolated from
other code. When a video card is misprogrammed, it is the most
temperamental type of perhipheral. But it isn't that hard to do it right,
and when that is done the stability is just fine.
> Likewise, NT stability (granted, always an
> iffy proposition) took a turn for the worse when Microsoft moved video
> drivers into ring 0 during the NT4 beta cycle, and it hasn't recovered.
NT's code is crap in general, design decisions aside. You can't
seriously take anything from it as an example of what to do or not to do.
Berlin's registrar was slammed because it is too much like the Windows'
registry. One of the Berlin developers made the good point that design
decisions should not be made assuming that your code will fail. There are
ligitimate architectural beefs to be had with the Registry, but the vast
bulk of the problems it causes are due to bugs. When you stomp the bugs
and it still doesn't work right, then complain.
> Then there's the OS/2 model: minimal drivers to map memory in ring 0, the
> rest of the privileged part of the drivers live in ring 2 (not 3). (This
> would also work for the sound drivers, come to think of it.)
I thought we didn't like microkernels here in Linux-land? I'd
love to be able to pull a lot of stuff besides video drivers out of the
kernel but not all the way into userland, but that isn't the way we do
things 'round here pardner. If we had a microkernel, X could have been
made into a priviledged driver process and this whole issue would have
been settled years ago. But we don't have a microkernel, we have a
traditional monolithic Unix kernel. All we have to work with is
userspace, root userspace and the kernel.
For my OS pragmatics class last fall, I and a partner had to write
our own microkernel OS. The whole thing was based on message passing
("mailboxes") and the device drivers, IPC mailbox hander, memory manager
and console system were all priviledged processes. I got to see some of
the downsides to microkernels (the message passing slowed everything
down), but the device driver processes were *heaven* to work with compared
to Linux device drivers. No fixed kernel APIs to conform to, no worries
about the drivers stomping on each other, no priviledge issues in the
driver, scheduling abilities *AND* critical sections simultaneously with
no hassles, etc etc etc. I though about trying to port KGI to the OS
("Das Boot", we called it) but I had too much other stuff on my plate at
that time to be able to do it.
Now, don't get me wrong. I'm not trying to say that Linus should
have written Linux as a microkernel OS, nor that he should do so now. We
have MkLinux and the HURD to play with there. Linus has some very valid
reasons for sticking with a traditional monolithic kernel, reasons that I
agree with. But if he has made that design decision, he should live by
it, and he is not doing so with X. In a monolithic OS, device drivers go
in the kernel. In a microkernel OS, device drivers are priviledged
processes. Pick one design and stick with it.
Just as NT (a microkernel) should have left the video drivers
outside the kernel, so too should Linux (a monolithic kernel) have the
video drivers in the kernel. NT has problems because the video drivers
and the kernel were not designed to be monolithic together. Obviously I
don't have access to the NT source, but I'll bet that this is responsible
for a lot of the stability problems. Linux currently has the opposite
problem. A monolithic Unix kernel is not designed to allow for device
drivers running as userspace processes, root or not.
The only reason that XFree86-Linux system hasn't collapsed in a
heap already is that, until fbcon, x86 Linux didn't do kernel graphics.
Now that is doing so, the flaws in this system will start to come thick
and fast. The inability of fbcon to multihead properly while using
XFree86 is just the first of many little "issues" that will continue to
pop up over the next little while, mark my words.
> You're doing your best to paint the situation as all one or all the other,
> nothing in between.
It is in between. That is the problem. Linux is a traditional
monolithic Unix kernel. There's no in between here - the drivers are
supposed to go in the kernel. I haven't heard one argument in support of
the current situation that didn't boil down to "It works and is
convenient". If that is good enough for you, fine. There's a lot to be
said for "just works and is good enough". Just don't take a "good enough"
hack and try to convince me that it is anything other than a hack.
> I regard such as overly simplistic and therefore
> strawmen.
The situation *is* really quite simple. Video drivers belong in
the kernel.
Jon
--- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html