All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Vojtech Pavlik <vojtech@suse.cz>
Cc: Kay Sievers <kay.sievers@vrfy.org>, Greg KH <gregkh@suse.de>,
	linux-kernel@vger.kernel.org, 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 10:44:36 -0500	[thread overview]
Message-ID: <d120d50005091608447d816585@mail.gmail.com> (raw)
In-Reply-To: <20050916080237.GD10007@midnight.suse.cz>

On 9/16/05, Vojtech Pavlik <vojtech@suse.cz> wrote:
> On Thu, Sep 15, 2005 at 08:23:43PM -0500, Dmitry Torokhov wrote:
> > On Thursday 15 September 2005 20:04, Kay Sievers wrote:
> > > I like that the child devices are actually below the parent device
> > > and represent the logical structure. I prefer that compared to the
> > > symlink-representation between the classes at the same directory
> > > level which the input patches propose.
> >
> > Why don't we take it a step further and abandon classes altogether?
> > This way everything will grow from their respective hardware devices.
> 
> That'd seem like a quite a good idea to me. ;)
> 

You just saying that ;)

Look at I2C/sensors people. They are moving from having every sensor
crampled into I2C bus to hwmon class so all the sensors can be easily
located (by some program or what's not).

> > Class represent a set of objects with similar characteristics. In
> > this regard event0 is no "lesser" than input0.
> 
> Well, input0 itself can't be accessed from userspace, so it's different.
> 

Why is this a factor? We are not talking about /dev here. We have a
lot of things in sysfs that are not directly accessible from
userspace.

> > Although they are
> > linked they are objects of the same importance. I do want to see
> > all input interfaces without scanning bunch of directories.
> 
> A directory with symlinks to all the interfaces of the class might make
> sense.
>

I'll try fix the patch I posted last night (that implements the above,
or at least what Kay described with sub-devices residing under their
parent devices and symlinked into their classes), I believe it could
also be used for block, so it will be like:

.../block/
|-- devices
|   |-- sda
|   |   |-- device -> ../../../../
|   |   |-- sda1
|   |   |   |-- dev
|   |   |   `-- device -> ../../../../../block/partitions/sda1
|   |   |-- sda2
|   |   |   |-- dev
|   |   |   `-- device -> ../../../../../block/partitions/sda2
...
`-- partitions
   |-- sda1 -> ../../../class/block/devices/sda/sda1
   |-- sda2 -> ../../../class/block/devices/sda/sda2

-- 
Dmitry

  reply	other threads:[~2005-09-16 15:44 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
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 [this message]
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=d120d50005091608447d816585@mail.gmail.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=airlied@linux.ie \
    --cc=dtor_core@ameritech.net \
    --cc=gregkh@suse.de \
    --cc=hare@suse.de \
    --cc=kay.sievers@vrfy.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.