Yes. The idea of the interpreter is to do things that have
to be (partly) in kernel space such as uninterruptable
sequences of register writes and interrupt handlers. These
would be very short sequences, less than 10 instructions
perhaps. Here performance is not so important. (Also if
you use it for reset-card-on-X-server-crash or virtual
console switches, performance is irrelevant).
For the actual accellerator code this should still be
done as far as possible directly from user space. This
also avoids the syscall overhead.
> code. However, maybe the interpreter could compile the code into native
> machine language.. In which case you might as well support any language
> that can turn the code into native machine language.
This is basically what modules are.
> If you would like to increase reliability, then maybe something like
> running a sub-kernel super-userspace thread that runs in one of the
> currently unused ring levels would be best.. But the overhead of switching
> between the different levels would probably slow things down a bit, not to
> mention that the ring level that a graphics driver would need to run at
> might still give it the ability to crash the system completely..
This is not worth the effort at all IMHO. Most processors don't
have all these ring levels anyway.
> I think the best way to increase reliability of graphics handling in linux
> would be to get all the people writing graphics drivers to come together
> and pool their knowledge (share code).. Hopefully the different efforts
As far as I can see, 90% of the people writing graphics drivers
are writing XFree86, so they already pool their knowledge and
share code. I am not personally unhappy about this at all, since
I like X. Also, the crossplatform nature of XFree86 is a strength
that we don't want to lose or work against.
-- Erik Corry- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu