|| ||Dmitry Torokhov <dtor_core-AT-ameritech.net>|
|| ||Greg KH <gregkh-AT-suse.de>|
|| ||Re: [PATCH] nesting class_device in sysfs to solve world peace|
|| ||Fri, 30 Sep 2005 00:32:49 -0500|
|| ||linux-kernel-AT-vger.kernel.org, Kay Sievers <kay.sievers-AT-vrfy.org>,
Vojtech Pavlik <vojtech-AT-suse.cz>,
Hannes Reinecke <hare-AT-suse.de>,
Patrick Mochel <mochel-AT-digitalimplant.org>, airlied-AT-linux.ie|
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
> 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.
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
to post comments)