Weekly Edition
Return to the Kernel page
| |||||||||||||
The udev tail wags the dog
It is not unheard of for kernel developers to refuse to support a
particular user-space interface that, they think, is poorly designed or
hard to maintain into the future. A user-space project refusing to use a
kernel-provided interface in the hope of forcing the creation of something
better is a rather less common event. That is exactly what is happening
with the udev project's approach to device tree information, though; the
result could be a rethinking of how that information gets to applications.
OLPC laptops have, among their other quirks, a special keyboard which requires the loading of a specific keymap to operate properly. For the older generations of laptops, loading this keymap has been easily handled with a udev rule:
ENV{DMI_VENDOR}=="OLPC", ATTR{[dmi/id]product_name}=="XO", \
RUN+="keymap $name olpc-xo"
This rule simply extracts the name of the machine from the desktop management interface (DMI) data that has been made available in sysfs. If that data indicates that the system is running on an XO laptop, the appropriate keymap file is loaded. DMI is an x86-specific interface, though, and the upcoming (1.75) generation of the XO laptop is not an x86-based machine. There is no DMI information available on that laptop, so this rule fails; some other solution will be needed. In current times, the source for hardware description information - especially on non-discoverable platforms - is supposed to be the device tree structure. So Paul Fox's solution would seem to make sense: he created a new rule with a helper script to extract the machine identification from the device tree, which happens to be available in /proc/device-tree. It almost certainly came as a surprise when this solution was rejected by udev maintainer Kay Sievers, who said:
Reading such things from /proc is kinda taboo from code we maintain
in udev. All things not related to processes really do not belong
into /proc and udev code should never get into the way of possibly
deprecating these things in the long run, even when they might
never happen. I know, there is sometimes no other simple option,
but we generally prefer the inconvenience it causes, over adding
hacks to upstream code, to make a move to a generally useful
solution (which isn't /proc/*) more attractive.
Of course, Paul wasn't adding the /proc/device-tree interface; criticism of such a move would not have been surprising. That file has a long history; it has been supported, under some architectures, since the 2.2 kernel. So one might think that it is a bit late to be complaining about it; there are a number of /proc files added in those days which would not be allowed into /proc now. In general, those files are considered to be part of the user-space ABI at this point; like it or not, we are stuck with them. The device tree file has been around for long enough that it almost certainly falls into that category; it's hard to imagine that it would have been maintained for so long if there were no programs making use of it. Whether or not the udev developers like it, /proc/device-tree is not likely to go anywhere else anytime soon. That still doesn't mean that the udev developers have to make use of it, though, and they seem determined to hold out for something better. Quoting Kay again:
No, sorry, the time for dirty hacks in userspace, and work-arounds
for architectures and platforms that don't provide what is commonly
used elsewhere is over. There is no rush, it's new functionality,
and no need to start with 'transitions periods' that in reality
will never end. Stuff just needs to be fixed properly these days,
and papering over just hurts us more in the end.
Kay would like to see the machine identification information exposed separately somewhere under /sys; it has even been suggested that platforms using device trees could emulate the DMI directory found on x86 systems. That, to them, looks like a longer-term solution that doesn't put udev in the position of blocking an ABI cleanup sometime in the future. In essence, what we have is a user-space utility telling the kernel that an interface it has supported for well over a decade is unacceptable and needs to be replaced. To force that replacement, udev is refusing to accept changes that make use of the existing interface. Whether that is a proper course of action depends on one's perspective. To some, it will look like a petty attempt to force kernel developers to maintain two interfaces with duplicate information in the hope that a long-lived /proc file will eventually go away, despite its long history. To others, it will seem like a straightforward attempt to help the kernel move toward interfaces that are more supportable in the long term. In this particular case, it looks like udev probably wins. Adding the machine identification somewhere in sysfs will be easy enough that it is probably not worth the effort to fight the battle. In a more general sense, this episode shows that the kernel ABI is not just something handed down to user space from On High. User-space developers will have their say, even a dozen years after the interface has been established; that is a good thing. Having more developers look at these issues from both sides of the boundary can only help in the creation of better interfaces. (Log in to post comments)
The udev tail wags the dog Posted Aug 25, 2011 1:46 UTC (Thu) by jonabbey (subscriber, #2736) [Link]
Neither my Fedora nor my RHEL boxes have a /proc/device-tree file.
Am I missing something?
The udev tail wags the dog Posted Aug 25, 2011 2:19 UTC (Thu) by corbet (editor, #1) [Link] You're not running a system that actually uses a device tree. x86 systems are (mostly) discoverable and don't need an external file to know what the layout of the hardware is.
x86 discoverability is over rated Posted Aug 25, 2011 9:41 UTC (Thu) by chrispe (subscriber, #4442) [Link]
I'd rather have a simple bootloader & device tree than an ACPI or EFI BIOS in my PC. Perhaps the BIOS could be chain loaded for OSes that need it.
x86 discoverability is over rated Posted Aug 28, 2011 3:33 UTC (Sun) by giraffedata (subscriber, #1954) [Link] I'd rather have a simple bootloader and device tree than an ACPI or EFI BIOS in my PC. Perhaps the BIOS could be chain loaded for OSes that need it. Where would your device tree come from? I presume you could install a new graphics controller in your PC; how would the device tree get changed so Linux and the things running under it know to drive it differently than the old one?
x86 discoverability is over rated Posted Aug 28, 2011 9:12 UTC (Sun) by nhippi (subscriber, #34640) [Link]
If the graphics adapter is on a enumerable bus such as PCI, bios or device tree have nothing to do with it. The Linux kernel PCI code will scan the bus and load the needed module.
Device tree/DMI are more useful in telling kernel about devices that cannot be automatically scanned. Usually such devices are "soldered on", so the need of changing the Device tree is quite rare.
Life in X86 and DMI is a bit more complicated, as Bios also probes some devices and puts them in DMI. Often instead of probing those devices in kernel again, we trust the bios with varying degrees of success.
x86 discoverability is over rated Posted Aug 28, 2011 19:18 UTC (Sun) by giraffedata (subscriber, #1954) [Link] OK, well I'm more confused than ever. On a system such as x86 that is discoverable, how does a user space program get the information that on other systems it gets from /proc/device_tree? And I presume there's a difference in how the kernel gets that information as well?(There was an article about this in LWN not long ago, but I didn't get it then either).
x86 discoverability is over rated Posted Aug 28, 2011 20:35 UTC (Sun) by robbe (subscriber, #16131) [Link]
As I understand it: the kernel gets its info from the BIOS (x86), bootloader or device tree. It puts the information in /sys/devices, on my x86-box under platform/, system/, and LNXSYSTM:00/ -- userspace can read the gory details there.
Seems like on this device-tree system some device is not ending up under /sys/devices, or too little actual info is put there, although the kernel had it handed to it via the device tree.
x86 discoverability is over rated Posted Aug 28, 2011 22:11 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
Most hardware on an x86 system is either a pretty fundamental part of the PC platform, on an enumerable bus such as USB or PCI, or described in ACPI. All these devices will appear in sysfs and will generate appropriate udev events, so userspace can load the appropriate drivers. The only other system information usually consumed by userspace is the DMI data, which is exposed in /sys/class/dmi/id .
x86 discoverability is over rated Posted Aug 28, 2011 23:04 UTC (Sun) by giraffedata (subscriber, #1954) [Link] Well so far, I'm not seeing anything that makes the adjective "discoverable" apply more to an x86 system than to one of these mysterious systems that has a /proc/device_tree. All I see is a different set of protocols for conducting discovery or reporting its results.
x86 discoverability is over rated Posted Aug 28, 2011 23:57 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
for x86 systems, most devices connect to a bus where you can send a query to the bus asking what devices are connected. The very small subset of devices that don't work this way tend to be devices that are standard across all manufacturers.
on many embedded systems (including ARM) this isn't the case. the kernel running on the system has no way of guessing what will happen if it sends data out to some I/O address. The kernel must be told about every device in the system and where it is.
it's the fact that almost every device on an x86 system is on a bus that can report what is there that makes the systems "discoverable"
x86 discoverability is over rated Posted Aug 29, 2011 0:28 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
Device tree and ACPI are both mechanisms for permitting discovery of non-discoverable devices. Device tree also provides metadata such as GPIO mappings, while ACPI abstracts that.
x86 discoverability is over rated Posted Aug 29, 2011 1:39 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
ACPI is a way for the kernel to lookup what hardware exists in tables created by the hardware manufacturer. The tables are (in theory) OS independant.
Device Trees are a way for the System Administrator who installs an OS on the system what hardware exists.
It's far more likely that the hardware manufacturer is going to accurately identify what hardware exists than it is that the System Administrator is going to know what hardware exists on a system.
Device Trees may look like they are discoverable if you are only looking at it from the point of view of an OS that has the Device Tree provided to it. But from the point of view of the person trying to install the system who has to figure out what to put in the Device Tree, they are not discoverable, they are the output of research, not the source of information.
x86 discoverability is over rated Posted Aug 29, 2011 2:15 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
The device tree is supposed to be provided by the boot loader, which in a typical ARM environment is supplied by the system vendor.
x86 discoverability is over rated Posted Aug 29, 2011 2:26 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
in a typical ARM environment the entire OS is provided by the system vendor, that's not a very good argument.
ARM vendors don't really care about Device Trees, they are pretty happy just hard-coding the kernel itself.
it's the people who want to upgrade the devices and people who want to maintain the upstream tree that want the consolidation made available by device trees.
x86 discoverability is over rated Posted Oct 18, 2011 16:15 UTC (Tue) by jcm (subscriber, #18262) [Link]
ARM vendors may care about enumerable device information if they are targeting general purpose Operating Systems as opposed to the existing tight vertical integration process.
x86 discoverability is over rated Posted Aug 29, 2011 0:32 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
Oh, ok, I think I see the confusion. /proc/device-tree is just a plain text representation of the device tree. It's to let developers work out whether the firmware's giving them something broken. Userspace should never need to use it, and that's why Kay's objecting to an attempt to make userspace use it. The reason it's an issue in this case is that there's no generic kernel interface to say "This machine is a model X made by manufacturer Y" - we'd use the DMI interface on x86, but DMI is a spec that doesn't exist on ARM.
Merge into the kernel? Posted Aug 25, 2011 2:36 UTC (Thu) by cesarb (subscriber, #6266) [Link]
Perhaps udev could be merged into the kernel, together with perf and kvm? ;-)
Merge into the kernel? Posted Aug 25, 2011 2:40 UTC (Thu) by josh (subscriber, #17465) [Link]
Seems like a perfect candidate.
Merge into the kernel? Posted Aug 28, 2011 20:17 UTC (Sun) by robbe (subscriber, #16131) [Link]
I would have liked that to happen in the early days of udev (two or three years ago), when it was often impossible to upgrade one of these without upgrading the other. Could get nasty if you tried to run a newer kernel on a stable/enterprise distro.
Now these birth pains are mostly gone, I see no pressing need to merge. So udev could serve as a poster child for the "incubator" idea proposed by dberkholz at https://lwn.net/Articles/456308/
Merge into the kernel? Posted Aug 27, 2011 0:42 UTC (Sat) by jcm (subscriber, #18262) [Link]
Make sure to merge gnome-shell while you're at it :-)
The udev tail wags the dog Posted Aug 25, 2011 4:43 UTC (Thu) by dilinger (subscriber, #2867) [Link]
I'd been hoping that a discussion on the devicetree-discuss list might yield some possible ways forward, but so far there haven't been a lot of responses to my post. :(
The udev tail wags the dog Posted Aug 25, 2011 17:47 UTC (Thu) by iabervon (subscriber, #722) [Link]
It's worth noting that the udev maintainer is also a kernel developer. So this is actually an instance of a kernel developer refusing to support a particular user-space interface that, he thinks, is poorly designed or hard to maintain into the future; the uncommon aspect is that he's doing it in his role as maintainer of a user-space project.
Linux Plumbers fail Posted Aug 25, 2011 18:03 UTC (Thu) by martin.langhoff (subscriber, #61417) [Link]
Thanks for covering this. My first reaction to Kay's argument was -- don't we have Linux Plumbers so these things get discussed and agreed upon?
There is a big push from the kernel side to consolidate platforms on using device-tree - see for example http://www.linaro.org/linaro-blog/2011/08/15/enabling-dev... -- but perhaps device-tree has not been discussed at a plumbers conference.
Linux Plumbers fail Posted Aug 25, 2011 20:11 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
It most certainly has been discussed at an LPC.
The nodes in a device tree are supposed to be bound to devices in the Linux device model. udev will then receive the information from those nodes through uevents and sysfs, just as it does for devices that are discovered on a PCI or USB bus. In this case some nodes with useful information are not bound to anything in the device model, and that should be fixed.
The udev tail wags the dog Posted Aug 27, 2011 0:47 UTC (Sat) by jcm (subscriber, #18262) [Link]
You know what I'd like to see, Jon? A story covering the brave new world we live in now that explains e.g. udev tags and its database, etc. I'd love to see this kind of stuff in a book but I've given up on the notion things will stay still long enough for that to happen.
|
|||||||||||||