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

Dmitry Torokhov
2005-10-06T17:40:12Z

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