Re: /dev/psaux-Interface

[Sau Dan Lee]

>>>>> "Jamie" == Jamie Lokier <jamie@xxxxxxxxxxxxx> writes:

    >> The input layer tries to do the same wrt HID devices and imo it
    >> makes sense. Why should userspace care if a mouse is attached
    >> to the USB port or via the USB->PS/2 connector thingy to the
    >> PS/2 port.

Isn't it  possible to use  the PS/2 AUX  port for purposes  other than
HID?  In 2.4,  /dev/psaux looks like /dev/ttyS1 to  the userspace.  Is
there a good reason to make them different in 2.6?


Imagine the kernel now hiding /dev/ttyS* and ASSUMING that all of them
are Class 2.0 fax-modems.  Instead of letting you issue the AT command
set  to the  fax-modem  and  getting the  response  directly from  the
device, the  kernel now *abstracts* that away  from usespace.  Imagine
that  the  kernel now  *forbids*  the  userspace  programs to  use  AT
commands directly.   Userspace is  now only allowed  to use  ioctls to
issue "dial", "hang  up", "receive fax page" commands.   Would that be
nice?

SEPARATION  of POLICY  and MECHANISM  is an  important concept  in the
design of unix.


And how about the display?  Shouldn't the kernel abstract it away from
userspace?   Why should  we  have different  XFree86 display  drivers?
Shouldn't they be  all implemented in kernel, so  that XFree86 and all
graphics programs only need to access the graphics system in a uniform
way, without  caring about the differences  between different graphics
adaptors?



    >> Requiring different configuration for both cases, and
    >> potentially even requiring different userspace applications for
    >> each type make it sound like abstracting this away from
    >> userspace does have merit.

You still need to configure your kernel by means of boot parameters or
module options.  Are users  already complaining about surprising mouse
sensitivity?  Don't  they need to  tune some parameters to  obtain the
desired behaviours?  I can't see  how you can do fewer configurations,
or avoid them at all.


    Jamie> I agree in this case: the touchpad should be handled by the
    Jamie> input layer, for uniformity if nothing else.

But why not do it in a user-space daemon?  GPM has been doing that for
10  years already,  and  it has  been  doing it  quite  well.  I  even
demonstrated to many  people how I configure both a  RS232 mouse and a
PS/2  mouse to  work in  X at  the same  time, and  those  people were
surprised that this was even possible.  Thanks to GPM.

My philosophy is: if something can be done in userspace, then do it in
userspace.  Only leave  the essential things in kernel  space.  So, we
don't have XFree86 in kernel space.  It's not a good idea.

Of  course,  if  performance  is  an issue,  we  may  consider  moving
something  from userspace  into kernel:  kernel NFS  daemon, firewall.
Isn't khttpd now removed?  Why?   (But even with knfsd, you still have
the CHOICE to use a userland nfsd instead.)  I don't believe 'gpm' has
performance problems -- the mouse port is usally 1200 baud only.


    Jamie> However, what happens when the thing connected to the PS/2
    Jamie> port isn't a mouse or keyboard, just a strange device
    Jamie> talking bytes?  With 2.4 kernels you could talk to it.

And  now...   it's not  possible  anymore.   Assuming that  everything
attached to the PS/2 AUX port must be a mouse is a design mistake.  It
is like assuming that the RS232 port must be attached to a fax-modem.




-- 
Sau Dan LEE                     ???(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@xxxxxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/