Re: [PATCH] nesting class_device in sysfs to solve world peace

[Michael Tokarev]

Dmitry Torokhov wrote:
> On Wednesday 05 October 2005 19:09, Greg KH wrote:
> 
>>On Fri, Sep 30, 2005 at 12:32:49AM -0500, Dmitry Torokhov wrote:
>>
>>>On Wednesday 28 September 2005 18:31, Greg KH wrote:
>>>
>>>>Alright, here's a patch that will add the ability to nest struct
>>>>class_device structures in sysfs.  This should give everyone the ability
>>>>to model what they need to in the class directory (input, video, etc.).
>>>
>>>I still do not believe it is the solution we want:
>>>
>>>1. It does not allow installing separate hotplug handlers for devices
>>>   and their sub-devices. This will cause hotplug handlers to resort to
>>>   having some flags or otherwise detect the king of class device hotplug
>>>   hanlder is being called for and change behavior accordingly - YUCK!
>>
>>Huh?  I don't understand your complaint here.  Why would we ever want to
>>have separate hotplug handlers for the same class?  If you do want that,
>>then create separate classes.
>>
> 
> 
> Yes. I do want separate [sub]classes. I just want them grouped together
> under some <subsystem> name. And I want separate hotplug handlers because
> actions that are needed for these objects are different. When a new
> input_dev appears you want to match its capabilities with one or more
> input handlers and load appropriate handler module if it has not been
> loaded yet. When a new input interface device appears you want to create
> a new device node for it. The handlers should be diffrent if you want
> clean implementation, do you see?

How about using current classes, but name them to have common prefix,
eg input_dev, input_interface etc class names - this way, if a program
wants to enumerare all input <whatever>, it enumerates /sys/class,
finds all directories matching input*, and looks inside...

Maybe not that elegant, but may work.

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