On Wed, Oct 15, 2003 at 08:38:44PM +0000, Raymond Jennings wrote:
> Oh my!
>
> Judging from the large number of *flames* I got for suggesting it, I guess
> a kernel module for X is not such a good idea after all.
It is not that it is not a good idea to consider, it is just a topic
that pops up now and again and has been brainstormed and fought about an
awful lot. (look up old posts about the GGI project to see some
spectacular flame wars). so don't take it personally, the truth is that
this is something that has been thought about. A lot of people here have
been involved in past flame wars and some of that probably got directed
at you.
> XFree86 *might* wish to consider a "modulette" to cover things that
> userland CAN'T do, like AGP, DMA, IRQ, and so on. Or maybe the modulette
> could grant I/O privileges on behalf of an X server that opens it (thus the
> X server doesn't require root privileges)? Perhaps some extensions to
> /dev/framebuffer? A smaller module may involve less overhead.
>
> Does the notion of a kernel module have ANY merit at all? Or was the idea
> complete garbage?
The notion of a kernel module does have merit. but is it worth it?
modern cards tend to be communicated with via memory maped IO, accessing
that directly from userspace is about as fast as one can get, involving
the kernel will just slow things down.
Another thing is that this is somewhat outside of xfree86s domain,
xfree86 is an X implementaton for many architectures and operating
systems, in a way it's goal is to be the best it can be given the
constraints of the system it is running on. if the kernel provides a way
to get at IRQs and whatnot then xfree86 can take advantage of it if it
makes sense, but dictating the design of the kernel is not right.
Also, there are kernel modules that do a lot of the things you mention,
agpart and DRI modules in particular. so this is already being done to
some degree and xfree86 takes advantage of it when it can. more small
general purpose modules will probably be written as the need for them
becomes clear.
the point is that it is not as simple as 'kernel fast'. kernel code is
not inherently faster than userspace code. (repeat this 3 times) and
context switching into and outof the kernel has a real cost as does the
maintienence of kernel code vs. portable userspace code.
hope this explains things better and lets you know why people seemed to
react the way they did to an innocuous question.
John
--
---------------------------------------------------------------------------
John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED]
---------------------------------------------------------------------------
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
