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> 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
Documentation/filesystems/sysfs.txt:

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

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


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