Messages in this thread | | | Subject | Re: [PATCH] serio.c: dynamically control serio ports bindings via procfs (Was: [RFC/RFT] Raw access to serio ports) | From | Sau Dan Lee <> | Date | 03 Jun 2004 07:54:33 +0200 |
| |
>>>>> "Dmitry" == Dmitry Torokhov <dtor_core@ameritech.net> 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@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/
| |