Re: [RFC] subclasses in sysfs to solve world peace

Kay Sievers
2005-09-16T01:46:55Z

On Thu, Sep 15, 2005 at 07:58:44PM -0500, Dmitry Torokhov wrote:
> On Thursday 15 September 2005 19:20, Greg KH wrote:
> > I would like to add something called "subclasses" for lack of a better
> > term. These subclasses would have both drivers, and devices associated
> > with them. This would show up as the following tree of directories:
> >
> > /sys/class/input/
> > |-- input0
> > | |-- event0
> > | `-- mouse0
> > |-- input1
> > | |-- event1
> > | `-- ts0
> > |-- mice
> > `-- drivers
> > |-- event
> > |-- mouse
> > `-- ts
> >
> > Here we have 3 struct class_devices like today, input0, input1, and
> > mice. We also have struct subclass_drivers of event, mouse, and ts.
> > These will create the struct subclass_devices event0, mouse0, event1,
> > and ts0. The "dev" node files will show up in the directories mice,
> > event0, mouse0, event1, and ts0, like you would expect them too.
>
> This proposed scheme does not answer the question: "what input interfaces
> present in my system?".

If this is really needed, we can just create a "interfaces" directory at
every "class" top-level and put symlinks pointing to all interfaces of that
class into it. How does that sound?

> Input interfaces are objects in their own right
> and deserve their own spot. Compare your picture with the one below:
>
> [dtor@core ~]$ tree /sys/class/input/
> /sys/class/input/
> |-- devices
> | |-- input0
> | | |-- device -> ../../../../devices/platform/i8042/serio1
> | | `-- event0 -> ../../../../class/input/interfaces/event0

> `-- interfaces
> |-- event0
> | |-- dev
> | `-- device -> ../../../../class/input/devices/input0
>
> Here you have exactly the same information as in your picture plus you can
> see the other class (input interfaces) as well.

Well, this is just putting two different classes into one subdirectory. :)
We would better just add "/sys/class/input_device" and don't need to change
any userspace software then.
Sure there is the cosmetical difference that the two classes are just named
input* and not live in the same directory, but that's not enough reason
to start a complete different model in sysfs, I think.

I would like to have the option to move "block" into "class" some day
and therefore prefer the "stacking class devices", compared to the "grouping
and symlinking" classes model.

Kay