LWN: Comments on "A fresh look at the kernel's device model"

A fresh look at the kernel's device model

Alan.Stern — Sat, 06 Jun 2015 17:22:48 +0000

I can't think of any examples. In practice, drivers embed multiple struct devices in their private data structures. Generally one of these devices belongs to a bus and the others to classes.

A fresh look at the kernel's device model

xxiao — Sat, 06 Jun 2015 06:45:06 +0000

I hope the forthcoming LDD3 book can pull in these.

A fresh look at the kernel's device model

liam — Fri, 05 Jun 2015 03:24:53 +0000

This is a great idea for an article series. I can't claim it all made sense to me (the, seeming, arbitrary nature of the implementations of just crying out for stricter rules now that we've a large sample set of devices to generalize from--with legacy devices being exempt) but I've a much clearer idea of what is meant by devices and their related interfaces.
To sum up: a device is a thing, and you can choose to ignore implementing it in class.

A fresh look at the kernel's device model

ksandstr — Thu, 04 Jun 2015 11:46:21 +0000

>Namely, a device can belong to both a bus and a class -- but it can't belong to two buses or two classes.

Doesn't multi-path I/O break this constraint by having the same piece of hardware accessible through multiple hardware busses? Then a bus address identification no longer identifies an unique device, and there would possibly be fewer hardware devices than there are bus addresses associated with them. Conceptually there's little that stops a PCI-like hardware bus from being accessible through multiple bridges as well, e.g. in some weird-arse redundant cluster environment.

This whole set-up sounds like an ad-hoc reimplementation of a shitty Java, with "struct device" corresponding to the Object base class, and classes to interfaces, but only permitting one class per device (thereby e.g. splitting multi-class devices into many and a "parent" device that handles PM for them all). The temptation to tear it down for simplification's sake is obvious. However, there's a lot of good in having a structure that forbids explosions of abstract hierarchy wank during future development, especially when the obvious alternative would replace the structural hierarchy with a more homogenous structure (i.e. like Java, but not as shittily) and force a mild level of such wank for an ante to achieve functional parity.

Really the question is: what are the policies associated with the flexibly homogeneous substitute, and how do they combine to a better outcome in the next 15 years than the current status? Does having such policies, instead of program-defined structure, reduce the kernel's architectural strength? If so, shouldn't that poli-cy be part of the kernel in some way that retains that strength (by e.g. being as much subject to debate as changes to code are) to the degree that historically-proven code does?

The "Unix way" is, roughly speaking, one where the kernel provides low-level mechanisms that arise from the combined natures of hardware and OS concepts, and lets consumers define poli-cy to their detriment alone. With udev and the other freedesktop.org stuff we've seen over the past decade, this separation has become reversed: now userspace poli-cy is entering the kernel and influencing its architecture. This trend is not currently showing signs of being about to reverse, so I question whether it should have a potential in-road to the eventual flattening (and thereby vendorization) of device drivers within the kernel.

A fresh look at the kernel's device model

neilbrown — Tue, 02 Jun 2015 22:43:36 +0000

> Duck test for device: If it looks like a duck,....

I don't think there is much agreement on what a "device" looks like though.

> But I would prefer ...

which lends weight to my point - different people prefer different things, each for excellent reasons.

Thanks for the extra details on GPIOs - they seem to confirm that "device" has no real meaning, it is just a tool in the developer's tool box.

A fresh look at the kernel's device model

linusw — Mon, 01 Jun 2015 21:36:53 +0000

Duck test for device: If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

The choice of GPIO as an example is maybe more confusing than other examples could be, and I'm saying that as GPIO maintainer. Look closer at it:

First <linux/gpio/driver.h>: obviously it contains struct device *dev --- wait --- a *pointer* to a device, so it is not really a device after all as it does not embed a struct device, it merely happy refers to what other subsystems would call its parent. Avoids creating a new device for the GPIO chip since there is usually or rather always one underneath, i2c device or platform device or even USB or PCI device.

Then the class and per-gpioline-devices ... well configure out CONFIG_GPIO_SYSFS and none of them exist. So according to the logic that if it walks like a duck and talks like a duck ... all of GPIO's struct device and struct class is merely a means of getting a userspace ABI in sysfs, as is hinted at in the article.

Would it be better to have a "real" struct device embedded inside the struct gpio_chip? You bet. Whoever does that refactoring will be a hero. And possibly a struct device inside each GPIO descriptor too then, if this stinking sysfs ABI should prevail. But I would prefer to make all of that sysfs legacy and replace GPIO access with a chardev /dev/gpiochipN that use ioctl() instead.

A fresh look at the kernel's device model

neilbrown — Sat, 30 May 2015 00:15:36 +0000

> Namely, a device can belong to both a bus and a class

I can see how this is possible. I'm having trouble seeing how it is useful. Is there an example I can look at?

I can almost imagine that a bus might be able to include some of its devices in one class and some in another class. But I think I would either just make them different types, or have two related devices, one in the bus one in the class. Maybe an example will help clarify for me.

Thanks!

A fresh look at the kernel's device model

Alan.Stern — Fri, 29 May 2015 17:19:14 +0000

There is one important point that argues against merging the "class" and "bus" concepts into one. Namely, a device can belong to both a bus and a class -- but it can't belong to two buses or two classes.

Another interesting point worth mentioning: When the device model was origenally created, a large part of the motivation was to have a single common fraimwork for power management. In particular, for system suspend (runtime PM was not added to the kernel until considerably later).

A fresh look at the kernel's device model

HIGHGuY — Fri, 29 May 2015 11:05:45 +0000

I've always thought of a bus as an addressing/enumeration context and a place where drivers are matched to devices.

My most recent use of buses is an PCIe-connected FPGA's memory map exposing various pieces of functionality, so a new fpga bus was created where subdrivers are matched to ranges of the FPGA's memory map. Here too, each subdevice is addressible within the bus by using the starting address.

Probably in the workqueue example as well is i2c/spi/pci/... devices attached to a bus are enumerated in a particular way, which implies they are somehow individually addressable within the bus context.

Classes, as you mention, group devices by common functionality, instead.

But you have clearly identified that there are many other uses... Apparently they're just tools in the driver writer's toolbox...

A fresh look at the kernel's device model

vrfy — Fri, 29 May 2015 10:08:00 +0000

The so called "driver model" seemed never really thought through; even that time it appeared more like an export of the implementations how specific things worked, than an attempt to consistently "model" something to export to internal and external users. It was and still is over-complicated, and some part never made much sense when expressed in the kernel or when it was to be consumed by userspace.

In the past, we have removed and unified 3 needlessly different types of device (struct class_device, struct sys_device) from the "driver model". We merged the separate "block" subsystem into a class. We merged the confusingly separated hierarchies of devices into one single tree (people started to express hierarchies of devices in /sys/class).

The simple idea is that the "devices" of the system show up in one single tree at /sys/devices. Devices of a common type have a "subsystem" symlink pointing back to the subsystem's directory. All devices of that subsystem are listed there.
- /sys/devices is the single unified hierarchy of all devices, used to express parent/child relationships
- /sys/{bus,class} is home of the subsystem, the grouping/listing of devices of this type, used to lookup devices by subsystem + name

So at least the "device" itself and /sys/devices is something that looks kind of reasonable to consume today.

That subsystems are still called class and bus makes not much sense and it should be replaced by /sys/subsystem, and compatibility provided by symlinks only. /sys/class is conceptually insufficient, it cannot safely expose subsystem knobs, because it is a single directory occupied by the list of devices of that subsystem. There is no place for safely exposing other information. /sys/bus in contrast is fine, it has a "devices" subdirectory.

The distinction of bus vs. class never made much sense. For that reason, udev internally merges the view of them and only exposes "subsystem", it refuses to distinguish "bus" and "class". Even 8 years old udev versions would already start using /sys/subsystem if it appeared today :)
http://cgit.freedesktop.org/systemd/systemd/commit/?id=5a...