[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.024 / U:2.984 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site