Nested class devices and the future of the device model [LWN.net]

Two weeks ago, this page looked at nested classes in sysfs as a way of representing the input subsystem device hierarchy to user space. This week, Greg Kroah-Hartman posted a set of patches with the latest version of class_device nesting; the selling feature this time around was that the patches "actually work." With this patch set, it is possible to create a hierarchy under /sys/class which represents the known input devices on the system and their relationship to the actual system hardware. Greg also notes that this patch set makes possible the long-anticipated move of /sys/block into the class hierarchy.

So all would seem to be well in sysfs land. But Greg finished his announcement with the following:

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.)

This note opened the floodgates to a wider discussion; it seems that a number of people are not entirely happy with the /sys/class hierarchy. Udev hacker Kay Sievers complained:

The nesting classes implement a fraction of a device hierarchy in /sys/class. It moves arbitrary relation information into the class directory, where nothing else than device classification belongs. What is the rationale behind sticking device trees into class?

What seems to have happened here is that a number of devices, mostly of the virtual variety, have found their home in the class hierarchy rather than with the other devices. As a result, the class tree has grown more complicated, and it has moved away from its original purpose, which was to be a way of grouping devices which share the same interface and function. So Kay (among others) has proposed that much of what is currently in the class tree be moved over to /sys/devices with the rest of the device information. The idea is that user space does not really care about the distinction between "real" and "virtual" devices, and the kernel interface should not either.

Greg, who holds a big vote on device model issues, has responded thusly:

Ok, I've spent a while thinking about this proposal and originally I thought it was the same thing we had heard years ago. But I was wrong, moving the class stuff into the device tree is the right thing to do, as long as we keep them as new "things" in the tree...

So it would seem that big changes are in store for the Linux device model. This code has grown and evolved considerably since its introduction in 2.5; it may be time for a big rework. Actually changing things without causing major pain for users could be a bit of a challenge, however. It will have to be approached carefully.

The plan under consideration for now is to simply try to solve the input subsystem problem for 2.6.15. That most likely involves the nested class_device patches, perhaps with some changes to avoid breaking things in user space (and udev in particular). Things look more ambitious in the longer term:

Then, we move the class stuff into real devices. There was always a lot of duplication with the class and device code, and this shows that there is a commonality there. At the same time, I'll work on making the attribute stuff easier and possibly merge the kobject and device structures together a bit (possibly I said, I don't know quite how much yet...)

The end result is that there is likely to be some significant churn in the device model code in the coming months. There will almost certainly be consequences for the driver API, and for user space as well. If it all works out, however, we should end up with a device model which is easier to understand and work with in both kernel and user space.

(Log in to post comments)