On Wed, 8 Oct 2003, Emmanuel ALLAUD wrote:I agree that we have to think of the usefullness of a kernel module. But I am pretty sure there are other problems which can be solved using it, moreover if the implementation is good, it could give us a clean API for hardware things (like DMA or whatever), think of the /dev/rtc as pointed earlier in this thread.
Juliusz Chroboczek wrote:
For this specific problem : I talked with M. Vojkovich about the yielding problem in that case, then we brought this to linux kernel guys (R. Russel and R. Love), both agreed to say that using sched_yield() will be really incorrect in 2.6, certainly to too much latency. They also both agreed to say that the solution is to use futex to sync the user space driver with the help of a kernel side which would poll the FIFO status (or whatever other conditions we want to wait for). They seemed to be interested in supporting that, so perhaps a joint effort could be successful on both sides so kernel can provide new services the X server could use.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.
TR> No, I don't think any of that is true.Implementing a kernel module might give access to more resources, like tighter console control, asynchronous accelerations,
DMA? Smarter polling of FIFO status? Retrace interrupt?
Bye
Manu
This is more of a hack than a solution. I still see little utility
in a kernel module.
Anyways I think it is worth to try and see what it can achieve (by the way does anybody know if DRI people have the same problem with FIFO/DMA?).
Bye
Manu
_______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
