> >> In both cases, stability was/is poor. In a unix system, hardware
> >> access is supposed to be through the kernel. See /dev and /proc.
Agreed. When the kernel controls hardware, you can always know
the state it is in (see below).
> > on Win95 and NT the video layer hits the hardware directly and is
> > kind of a ring 0 process - like ours.
>
> Only the plain console is ring 0. You can kill your X server.
> With a Cirrus board at least, you can't even fix the result with
> a warm reboot. The out-of-memory policy makes it easy to kill X.
OK, so we are confronted with (loads of?) broken hardware outthere.
We can't just ignore it, so we'll have to think up a solution to
this problem.
If GGI is a solution, why not use it (as a config option of course,
it will eat to much memory on a 386sx/4mb used as a router).
It might not be stable enough for mainstream use, so we could flag
it with CONFIG_EXPERIMENTAL instead...
I for one would be interested in at least testing GGI (even though
I don't have 'broken HW'...
Rik.
-- Send Linux memory-management wishes to me: I'm currently looking for something to hack...