All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vojtech Pavlik <vojtech@suse.cz>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Greg KH <gregkh@suse.de>,
	Dmitry Torokhov <dtor_core@ameritech.net>,
	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 09:59:08 +0200	[thread overview]
Message-ID: <20050916075908.GC10007@midnight.suse.cz> (raw)
In-Reply-To: <20050916010438.GA12759@vrfy.org>

On Fri, Sep 16, 2005 at 03:04:38AM +0200, Kay Sievers wrote:
> On Thu, Sep 15, 2005 at 05:20:37PM -0700, Greg KH wrote:
> > The problem:  We need a way to show complex class and class device
> > structures properly in sysfs.  Examples of these "complex" views are the
> > input layer's use of different input drivers for devices (usually the
> > same device), the video subsystem view of frame buffer devices and
> > monitors, and even the block layer with it's disks and partitions.
> > 
> > Proposed solutions in the past have been either add the ability to nest
> > classes themselves (as shown in Dmitry's recent proposal for fixing the
> > input layer), or add the ability to nest class_device structures (I
> > think others have tried to do this in the past, sorry for not
> > remembering the specifics.)  Both of these proposals don't really solve
> > the real problem, that of the fact that we need to come up with a
> > solution that all of the different subsystems can use properly.
> > 
> > So, here's my take on it.  Feel free to tell me what I messed up :)
> > 
> > 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
> 
> 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.

I like this one better, too. It's much simpler, and does the job just as
well.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

  parent reply	other threads:[~2005-09-16  7:59 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
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 [this message]
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=20050916075908.GC10007@midnight.suse.cz \
    --to=vojtech@suse.cz \
    --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 \
    /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.