lkml.org 
[lkml]   [2004]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: /dev/psaux-Interface
From
Date
>>>>> "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/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.071 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site