Nested class devices and the future of the device model

[Posted October 19, 2005 by corbet]

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.

to post comments

Nested class devices and the future of the device model

Posted Oct 20, 2005 15:57 UTC (Thu) by kleptog (subscriber, #1183) [Link] (7 responses)

You know, this is one of those moments where I *really* wish there was an unstable branch on the Linux kernel that had this kind of development. I'm reading emails on the Debian lists about packages like udev and hotplug that imply basically they work with versions 2.6.8 to 2.6.12 but after that you need something else and it looks like they're going to change it again...

This makes me very wary upgrading to 2.6 (I'm still on 2.4.27) since I *really* don't want to spend ages getting my module loading sorted out. I spent long enough getting it working here, I'm not just going to throw it all to the wind to see if it works.

So here's me asking: when do we get a stable kernel with a compatable userspace all at the same time?

Nested class devices and the future of the device model

Posted Oct 20, 2005 16:31 UTC (Thu) by gregkh (subscriber, #8) [Link] (1 responses)

Use a distro other than Debian :)

Seriously, other distros have this all sorted out just fine. Use Gentoo,
Fedora, SuSE, Slackware, etc. Or, if you want a _real_ stable 2.6 kernel,
that is supported and maintained for a number of years, pick an
"enterprise" distro like SLES or RHEL or even Ubuntu.

You have options, you don't have to live on the bleeding edge of
the unstable Debian or Gentoo or Rawhide tree to take advantage of
the 2.6 kernel and its benifits.

Nested class devices and the future of the device model

Posted Oct 20, 2005 22:09 UTC (Thu) by hmh (subscriber, #3838) [Link]

Other than Debian **UNSTABLE** you mean.

Nested class devices and the future of the device model

Posted Oct 20, 2005 18:57 UTC (Thu) by iabervon (subscriber, #722) [Link] (2 responses)

If there were an unstable branch, it would presumably break compatibility with 2.6, and it would be intended to become the future arrangement. And you would therefore definitely be wasting effort moving to 2.6, because the stuff you'd use wouldn't even be intended to work long-term. Having stable and unstable branches doesn't in any way resolve compatibility issues; it's just an excuse for breaking things.

I'd even venture to say that the fact that you're still using 2.4 and not 2.6 is that there's a lot of incompatibility due to the 2.5 series in between. Going from 2.6.0 to 2.6.13 breaks compatibility less than 2.4.27 to 2.6.0, even though there is more total change, because there isn't the expectation that there will be a major transition that changes everything.

Nested class devices and the future of the device model

Posted Oct 20, 2005 20:08 UTC (Thu) by kleptog (subscriber, #1183) [Link] (1 responses)

Maybe, maybe not. Near as I can tell you need different versions of udev and hotplug depending on whether you're running 2.6.8, 2.6.13 or (soon) 2.6.16. No matter which way you turn it they're changing user-visible interfaces every other release in a backward incompatable way.

It's a change though. During the 2.4 series I would regularly upgrade my kernel, fairly secure in the knowledge that after the reboot everything would just work. With 2.6 you upgrade and find that your module loading just broke, again. I'm glad there's a lot of guinea pigs out there willing to test the stuff, because I have a day job and work to do. Call me back we 2.8 releases and 2.6 stablises.

Nested class devices and the future of the device model

Posted Oct 20, 2005 21:22 UTC (Thu) by iabervon (subscriber, #722) [Link]

Switch to 2.6.13.x, and apply backported security patches. The new scheme essentially pushes the "everything stays the same" level down a digit, so 2.6.13 to 2.6.14 is essentially like 2.2 to 2.4, except that it won't break nearly as much. The main caveat is that I think it's worth waiting either for 2.6.x.1 or for 2.6.x to turn out stable, because the quality control on 2.6.x as first released isn't that good; 2.6.x is the point at which the version is turned over to the "stable" maintainers, not their first release.

I also haven't heard anything about module loading breaking, except for between 2.4 to 2.6. There has been code that's had bugs, and if it's built as a module, it causes problems when you load it, but that's hardly the same thing, and it isn't unlike problems that crop up on occasion in 2.4.

Nested class devices and the future of the device model

Posted Oct 23, 2005 6:42 UTC (Sun) by thedevil (guest, #32913) [Link]

Solution: ditch udev and hotplug, and compile a mostly monolithic kernel
for the hardware you have.

Just download one of the linux-source-2.6.x packages, untar
in your home directory, make menuconfig, and make. You won't die
a horrible painful death, I promise.

Nested class devices and the future of the device model

Posted Oct 23, 2005 23:03 UTC (Sun) by zblaxell (subscriber, #26385) [Link]

"they work with versions 2.6.8 to 2.6.12 but after that you need..."

...new versions of udev and hotplug to match, installed before rebooting.

Actually you don't *need* anything. I'm running 2.6.13.2 with udev 0.056 (Debian), and it works just fine in the default configuration. I have udev on hold at the moment as it seems that some or all later versions of udev are severely broken regardless of kernel version--after a few bad reboots I put everything on hold, and will revisit this problem the next time some other package forces me to upgrade udev.

AFAICT, with recent udev versions all of your old udev user-space configuration breaks, and you get new features that weren't in older udevs. It's possible that some really new devices or features in the kernel are therefore not supported at all by older udev, but that means new stuff won't ever work, not that old stuff that previously worked breaks. Of course if you had non-default configuration, it has most likely reverted to the default.

If you have a static /dev tree on your root filesystem, it will still work in 2.6.13 whether you use udev or not (assuming udev *itself* isn't broken, in which case it will be broken no matter what kernel you use). If you rely on a tmpfs-mounted /dev supplied by udev versions later than 0.056...I don't know what happens.

The biggest change IMHO between 2.6.12 and later kernels is that devfs went away. It's necessary to do some gymastics with 'mount --bind' to get the original root filesystem and make a '/dev/console' in it so that the subsequent reboot will succeed (assuming you've also installed udev)--my systems have had empty /dev on the root filesystem for some years now. This is such a huge, all-encompassing, all-breaking change, that it's pointless to discuss the various udev flavors.