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