Messages in this thread | | | Date | Thu, 6 Oct 2005 12:40:08 -0500 | From | Dmitry Torokhov <> | Subject | Re: [PATCH] nesting class_device in sysfs to solve world peace |
| |
On 10/6/05, Michael Tokarev <mjt@tls.msk.ru> wrote: > 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. >
We have it right now (see /sys/class/{ieee1394_*|scsi-*|usb_*}) and it pretty much sucks IMHO. I would like to move from a flat class model to a more tree-like structure.
-- Dmitry - 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/
| |