[patch 0/8] Nesting class_device patches that actually work

[Greg KH <gregkh@suse.de>]

Ok, finally.  Here's a set of _working_ patches that properly implement
nesting class_device structures, and the follow-on patches to move the
input subsystem to use them.  Hotplug and release functions work
properly now, and this will let us move /sys/block/ to use class and
class_device structures soon.

The input patches are on top of almost all of Dmitry's input patches.
All of them are together in one series in my public patches at:
	kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
and should show up in the next -mm release.

The sysfs tree looks the same as it did last time, but now hotplug works
properly for addition and removal, and we actually free the memory used
:)

For those that don't remember, here's the sysfs tree on my desktop:
$ tree /sys/class/input/ -d
/sys/class/input/
|-- input0
|   |-- capabilities
|   |-- event0
|   `-- id
|-- input1
|   |-- capabilities
|   |-- device -> ../../../devices/platform/i8042/serio1
|   |-- event1
|   |   `-- device -> ../../../../devices/platform/i8042/serio1
|   `-- id
|-- input3
|   |-- capabilities
|   |-- device -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0
|   |-- event2
|   |   `-- device -> ../../../../devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0
|   |-- id
|   |-- mouse0
|   |   `-- device -> ../../../../devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0
|   `-- ts0
|       `-- device -> ../../../../devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0
`-- mice

To answer the remaining questions from the last thread:

Q: how are you going to determine what is really a class_dev and what
   isn't, as there's no way to tell.
A: Who cares?  Seriously, tools like udev will watch for the "dev" file
   to be able create the required device node, and it will be the one
   getting the hotplug event.  attribute groups do not generate hotplug
   events, and you should not be having a file called "dev" in your
   attribute group anyway.

Q: why does event2, mouse0, and input3 in the above tree all have the
   same "device" symlink?
A: userspace tools expect that symlink there.  They do not know that if
   you traverse up a directory, and look at the symlink there, that's
   what the subdirectory points to too.  That would be a mess.  And, as
   those different class_device structures really are all bound to that
   same struct device, that is the proper representation of this.

Q: How can you determine between input interfaces and input devices?
A: input devices have a "dev" file.  And what really does userspace need
   to know here?

Q: Wait, what about nesting struct class instead?  That would work,
   right?
A: No, nesting classes is not going to happen.  Classes are "major"
   things, and aren't related to each other (well, some are by their
   name only, like the different "scsi*" classes, but to the user, they
   are separate.)
   Also, we can't emulate /sys/block with nested classes.  And no, we
   can't change this to be /sys/class/block/partitions and
   /sys/class/block/devices without almost every sysfs user complaining
   loudly.  That's not the real representation of the devices, and we
   need to really try to keep backward compatibility where we possibly
   can.

Ok, I think that covers everything.

Oh, one final thing.  I really don't think that input should be a class.
It looks like a "bus" and acts like a "bus" (you have different devices
that have different drivers bind to them, and you want to load those
drivers with the hotplug mechanism.)  The only thing keeping this from
being a bus is the fact that we can't bind multiple drivers to a single
device these days, and I can't see a way to move this code to that
model, so oh well...

thanks,

greg k-h