>> I'd like to suggest that you implement device-specific code as a kernel
>> module.
Well, that won't happen; we already have working portable driver code
in userspace, and there's no chance we'll port that to the Linux kernel.
On the other hand, I do think that we'll end up using more kernel-side
functionality than we currently do; perhaps someday we'll have enough
of that to be able to run non-root servers, at least on hardware that
does memory-mapped I/O (the iopl system call is for root only).
TR> The key problem with this is that kernel modules are Linux-specific, and
TR> further often need to be kernel-version specific. XFree86 runs quite well
TR> in many non-Linux environments today.
But that doesn't prevent it from using features specific to Linux when
needed. Notice for example the use of the vm86old syscall in the
Linux/i386 version of the int10 module, or the (optional) use of fbdev
in quite a few drivers, or the future use of the /dev/input/event
devices (hint, hint). Let alone the DRI.
>> Implementing a kernel module might give access to more resources, like
>> tighter console control, asynchronous accelerations,
TR> No, I don't think any of that is true.
DMA? Smarter polling of FIFO status? Retrace interrupt?
The /dev/rtc driver is an example of a kernel module with the sole
purpose of giving userspace access to an interrupt.
TR> For security reasons, wouldn't you want to restrict access to the kernel
TR> module to root programs anyway? You don't want arbitrary code accessing
TR> your video card and changing the mode.
There's normal Unix security for that; make a group xfree86, and put
the users allowed to run the server in that group. Or make the server
setgid xfree86, which is better than setuid root.
Of course, I'm not arguing that it should be done, just pointing out
that you're too fast dismissing the idea of having some tailor-made
code on the Other Side.
Juliusz
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
