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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
