|| ||Greg KH <firstname.lastname@example.org>|
|| ||Patrick Mochel <email@example.com>, firstname.lastname@example.org|
|| ||[RFC] Device class rework [0/5]|
|| ||Tue, 22 Apr 2003 13:55:45 -0700|
|| ||email@example.com, firstname.lastname@example.org|
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
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, 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
- 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
- cpufreq changes. This converts the cpufreq code to the new driver
- 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.
 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 email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/