Messages in this thread | | | Subject | Re: /dev/psaux-Interface | From | Sau Dan Lee <> | Date | 21 Apr 2004 13:24:56 +0200 |
| |
>>>>> "Neil" == Neil Brown <neilb@cse.unsw.edu.au> writes:
Neil> I agree that it is good for the kernel to provide hardware Neil> abstractions, and that "mouse" is an appropriate device to Neil> provide an abstract interface for.
So, the next step is to port efax or Hylafax into kernel space. Why leave the /dev/ttyS? hanging out there? Why not encapsulated them and provide a /dev/fax that does what efax or Hylafax do?
And then, it's time to port Ghostscript and lpd into the kernel. Why leave the raw /dev/lp0 there? Why not move abstract them and provide a /dev/postscript_printer instead? Why lpd? Have a virtual filesystem pqfs, so that we can easily copy postscript files to that fs (instead of lpr), use ls to inspect what print jobs are there (instead of lpq) and use rm to remove pending jobs (instead of lprm)?
Neil> It does not follow that all drivers below that abstraction Neil> should live in the kernel.
Exactly! Look at autofs and nfs. The respective daemons are in userland (I know there is knfsd -- as a OPTION). Why? Why not move them into the kernel altogether? What's the advantage of implementing these daemons in userland? That's exactly the advantage of handling mouse protocol using a gpm-like program.
Neil> I have a userspace program that talks to my ALPS touchpad Neil> (through a hacked /dev/psaux that talks direct to the psaux Neil> port) and converts taps etc into "input layer" messages that Neil> are passed back into /dev/input/uinput.
That's what I have in mind: have a userland daemon that bridges between the raw port and uinput. This leaves great flexibility for the daemon to do whatever the writer feel appropriate. I hope you agree that it is easier to develop and debug programs in userland and in kernel space. Providing API for such a daemon would provide fertile soil for people to implement different useful things.
BTW, how did you hack the /dev/psaux?
Neil> I did consider writing a kernel driver for the ALPS Neil> touchpad, but due to the dearth of documentation and the Neil> fact that it seemed very hard to automatically detect it, I Neil> decided that such a driver would be too hard to support.
So, writing userland programs are generally easier than having to touch the kernel -- even when you're just writing a module. A daemon that seg-faults doesn't hurt. A daemon that runs into infinite loops can be killed. It's much safer and easier to implement the mouse protocol interpreter in userland. And I guess 'gpm' and its dozens of drivers can be more easily transformed into a bridge between /dev/psaux or /dev/ttyS? (or even a TCP/UDP socket!) and uinput. I'll bet on gpm, given its maturity vs. the kernel 2.6 mouse drivers.
Neil> So here is my vote in favour of "Let's make /dev/psaux a Neil> clean channel to the PS/AUX device" - at least Neil> conditionally.
I second! Let's free /dev/psaux. We want the /dev/psaux as in 2.4, 2.2, 2.0, ... We don't want a faked, censored one as in 2.6.0--5.
-- Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)
E-mail: danlee@informatik.uni-freiburg.de Home page: http://www.informatik.uni-freiburg.de/~danlee
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |