[lkml]   [2004]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] serio.c: dynamically control serio ports bindings via procfs (Was: [RFC/RFT] Raw access to serio ports)
>>>>> "Dmitry" == Dmitry Torokhov <> 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)

Home page:

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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