Messages in this thread | | | Date | Fri, 16 Sep 2005 09:59:08 +0200 | From | Vojtech Pavlik <> | Subject | Re: [RFC] subclasses in sysfs to solve world peace |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |