Messages in this thread | | | Date | Tue, 22 Apr 2003 13:55:45 -0700 | From | Greg KH <> | Subject | [RFC] Device class rework [0/5] |
| |
Hi,
Here's a set of patches that rework the current class support in the kernel today into something that works a bit better, and is simpler to use.
Currently, classes are assigned to drivers at compile time (or at the latest, at driver_register() time) and enforce a 1 to 1 relationship between class devices and struct device objects. This is not practical in the kernel, as there are a number of physical devices that correspond to multiple "class" devices. It's also unwieldy to bind classes to devices so early. They should be explicitly done later when the class device is registered with that subsystem.
So with that in mind, here's some changes. The rework of the driver core is all done right now in one big patch, but I'll split it up smaller for inclusion later on.
This patch gets rid of struct device_class and struct device_interface, and replaces them with struct class[1], struct class_device, and struct class_interface. struct class is much like struct device_class used to be, but is much smaller, and not bound to any drivers. This makes the driver core a lot smaller, as we get hotplug events for free now (struct class_device is a kobject), and is more flexible.
A struct class_device is registered with a class when that device is registered within the kernel. As an example of this, see the tty patch later on in this email thread.
A struct class_interface is used to get a callback whenever a struct class_device is registered or unregistered with a class. This can be used to attach files to the class_device, or do more complicated things. The patch that changes the cpufreq code in this email thread shows how this can be used (although the cpufreq code can be further simplified based on these changes, I've not done it yet.)
If there are no major objections to this, I'll split it up into smaller pieces for inclusion in the kernel tree.
I'll follow this message up with 5 patches that do the following things: - all of the driver core conversions. This is the meat of the changes. - Fixes for the input core to build properly. I've not converted the input core to the new class model yet, but will after this. - Crude patches to the scsi core to get it to build properly. This patch is not correct, but needed if your machines have scsi. Mike Anderson has said he will fix up the scsi code based on these core changes. - cpufreq changes. This converts the cpufreq code to the new driver class changes. - tty changes. This converts the tty code to the new driver class changes. With this patch, we now show all tty devices, and their device major/minor number in the /sys/class/tty/ directory. Yes, this is still a bit crude (all ptys are shown, and they should not be), but it's an example of why these changes are needed, and how to add class support to a subsystem. I'll rework this after Christoph's and Al Viro's tty changes are in the main tree, as we all are touching the same part of code.
Oh, and I didn't touch the pcmcia code yet either, with these patches, that code will not compile properly.
Any comments?
thanks,
greg k-h
[1] Yes, that's "struct class", and yes, I mean it. If you don't like it, please propose something else that describes what it does. - 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/
| |