From: Kay Sievers <kay.sievers@vrfy.org>
To: Dmitry Torokhov <dtor_core@ameritech.net>
Cc: Greg KH <gregkh@suse.de>,
linux-kernel@vger.kernel.org, Vojtech Pavlik <vojtech@suse.cz>,
Hannes Reinecke <hare@suse.de>,
Patrick Mochel <mochel@digitalimplant.org>,
airlied@linux.ie
Subject: Re: [RFC] subclasses in sysfs to solve world peace
Date: Fri, 16 Sep 2005 03:46:52 +0200 [thread overview]
Message-ID: <20050916014652.GA12920@vrfy.org> (raw)
In-Reply-To: <200509151958.45573.dtor_core@ameritech.net>
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
next prev parent reply other threads:[~2005-09-16 1:46 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-16 0:20 [RFC] subclasses in sysfs to solve world peace Greg KH
2005-09-16 0:58 ` Dmitry Torokhov
2005-09-16 1:46 ` Kay Sievers [this message]
2005-09-16 1:58 ` Dmitry Torokhov
2005-09-16 21:54 ` Greg KH
2005-09-16 1:04 ` Kay Sievers
2005-09-16 1:23 ` Dmitry Torokhov
2005-09-16 1:54 ` Kay Sievers
2005-09-16 2:03 ` Dmitry Torokhov
2005-09-16 2:14 ` Kay Sievers
2005-09-16 2:36 ` Dmitry Torokhov
2005-09-16 2:43 ` Kay Sievers
2005-09-16 3:10 ` Dmitry Torokhov
2005-09-16 7:21 ` Dmitry Torokhov
2005-09-16 21:48 ` Greg KH
2005-09-16 22:55 ` Dmitry Torokhov
2005-09-16 8:02 ` Vojtech Pavlik
2005-09-16 15:44 ` Dmitry Torokhov
2005-09-16 21:50 ` Greg KH
2005-09-16 22:56 ` Dmitry Torokhov
2005-09-17 0:48 ` Dave Airlie
2005-09-16 21:49 ` Greg KH
2005-09-16 7:59 ` Vojtech Pavlik
2005-09-16 21:55 ` Greg KH
2005-09-16 22:45 ` Dmitry Torokhov
2005-09-17 0:20 ` Antonino A. Daplas
-- strict thread matches above, loose matches on Subject: below --
2005-09-16 1:45 David Lang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050916014652.GA12920@vrfy.org \
--to=kay.sievers@vrfy.org \
--cc=airlied@linux.ie \
--cc=dtor_core@ameritech.net \
--cc=gregkh@suse.de \
--cc=hare@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@digitalimplant.org \
--cc=vojtech@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox