Re: [PATCH] serio.c: dynamically control serio ports bindings via procfs (Was: [RFC/RFT] Raw access to serio ports)

[Sau Dan Lee]

>>>>> "Dmitry" == Dmitry Torokhov <dtor_core@xxxxxxxxxxxxx> writes:

    Dmitry> Let me start with saying that this is a very good patch
    Dmitry> and that is exactly what I have in mind with regard to
    Dmitry> serio port/device binding.  The only problem with the
    Dmitry> patch is that it uses wrong foundation, namely procfs,
    Dmitry> because:
    ...
 
    Dmitry> So we have several options - if we adopt procfs based
    Dmitry> solution now we will have to maintain it for very long
    Dmitry> time, along with competing sysfs implementation. Dropping
    Dmitry> one kernel parameter which will never be widely used is
    Dmitry> much easier, IMO.

It's not just the matter of dropping one kernel parameter.  The procfs
support, _already  implemented_, allows  one to fine-tune  the binding
between serio  ports and  devices, which is  a new and  useful feature
that  your kernel  parameter  doesn't provide.   

Can you unbind the keyboard port?   Can you bind/unbind any of the AUX
ports  *dynamically*  without   reloading  the  i8042  module?   These
functionalities are  already there in the serio-related  code.  Just a
userland interface is missing.  My patch is to fill this gap.



    Dmitry> So I propose we all join our ranks and tame that sysfs
    Dmitry> together ;) I had some patches that were converting
    Dmitry> drivers to the sysfs adding them to serio bus, 

sysfs  looks  good  for  simple parameters:  integers,  strings.   For
anything more  complicated (sets, graphs),  I don't see it  fit (yet).
Unfortunately, the serio port<-->device relation is already a graph (1
to n).

I'd like  to see  how you implement  the device<-->handler  binding in
input.c using sysfs.  It'd be a nice feature.  Imagine how annoying it
is for 'evbug' to report your keypresses, when you're just debugging a
mouse driver.   Being able to adjust the  device<-->handler binding is
what I  want.  I don't  care whether it's  a procfs approach  or sysfs
approach, as long as it is  reasonably useable.  (You could even do it
with ioctl(), if you provide a  nice command line tool so that I don't
need  to care about  the ioctl  parameters.)  I'm  not going  to touch
input.c,  because  I  don't  want   to  reboot  everytime  to  test  a
modification.  It's hard to compile input.c as a module.



-- 
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/