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

[Vojtech Pavlik]

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