[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> 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.

Dmitry> What I was trying to say is serio and input system will
Dmitry> have sysfs support,

Then, why are you saying "dropping one kernel parameter"?

>> Can you unbind the keyboard port? Can you bind/unbind any of
>> the AUX ports *dynamically* without reloading the i8042 module?
>> These

Dmitry> No, and I was not trying to. It is just a stop-gap measure
Dmitry> to help end users to get their PS/2 devices working until
Dmitry> we have proper infrastructure in place.

I think direct access to PS/2 devices must stay there for the whole
2.6.x. It's unreasonable to assume that all existing _and working_
drivers will be kernelized.

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

Dmitry> Sysfs provides all the same features as procfs (I mean you
Dmitry> write read/write methods and have them do whatever you
Dmitry> please) but it also has benefits of your stuff integrating
Dmitry> with the rest of devices into a hierarchy.

It's different. Procfs is more versatile. I can stuff in my own
struct file_operations to do more than just read() and write(). I can
even stuff in my own struct inode_operations if I want more.

Another problem with sysfs is the "social" discipline as mentioned in

Attributes should be ASCII text files, preferably with only
one value per file. It is noted that it may not be efficient
to contain only value per file, so it is socially acceptable
to express an array of values of the same type.

Mixing types, expressing multiple lines of data, and doing
fancy formatting of data is heavily frowned upon. Doing these
things may get you publically humiliated and your code
rewritten without notice.

It is common in procfs to format the output nicely, and to display
screenfuls of information. This is to be frowned upon in sysfs.
Currently implementations of sysfs interface do follow this rule

Unfortunately, the connection between devices and drivers (either in
the serio.c interface or in the input.c interface) is a graph. It is
more complicated than an array. Yes, you can represent a graph with a
matrix or an adjacency list, both representable as arrays in one way
or another. Nothing in a digital computer cannot be represented by an
array of bits anyway! But useability of the interface must not be

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.043 / U:17.760 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site