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

[Dmitry Torokhov <dtor_core@ameritech.net>]

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.).
> 
> Dmitry, care to update your input patchset to take advantage of this?
> It should work out for what you want to do, and if not, please let me
> know.
> 
> udev will have to be changed to properly support this, but I think that
> Kay already has that taken care of, and is just waiting for some kernel
> code to take advantage of this.
> 
> Comments?
> 

Hi Greg,

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!

2. It does not allow user/program to scan for devices of given subclass.
   I understand that you want to tech udev about all existing handlers
   and having hotplug events allows to filter out unneeded names but for
   other programs I do not think we want to do that. Again, consider task
   of wanting to know all input interfaces, ot all available partiotions
   in a system. Do not say that the program has to know that there are hdX
   and sdX and ubX and adopt every time new type of device comes along
   since you would need to determine whether the name you see is an
   ordinary attribute or attribute group or the subdevice you are interested
   in. You can't really rely on presence of 'dev' attribute since subdevice
   does not have to have it. A better way would be to do
   "ls /sys/class/block/partitions/" or "ls /sys/class/input/interfaces"
   and get all this information.

3. It does not work well when you have an object that in your model is a
   logical subdevice but does not have a parent (or has multiple parents).
   Consider 'mice' multiplexor. Where would you put it? Together with
   inputX? But it is not an input_dev, it should not be there.

4. subdevice should have only one parent, your implementation allows to
   link subdevice to a class device and a real device at the same time,
   which IMHO is wrong. Only top-level class devices should be linked with
   physical /sys/devices/ device. 

I firmly believe that creating sub-classes (which solves hotplug issues)
and linking sub-class devices to their parent via 'device' link, much like
we link top-level class device to their physical parent devices (which
solves 2, 3 and 4) is much cleanier way. It provides everything that your
implementation does plus allows different views useful for other tasks
besides udev.

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