LWN: Comments on "The udev tail wags the dog"

x86 discoverability is over rated

jcm — Tue, 18 Oct 2011 16:15:11 +0000

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

dlang — Mon, 29 Aug 2011 02:26:31 +0000

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

mjg59 — Mon, 29 Aug 2011 02:15:31 +0000

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

dlang — Mon, 29 Aug 2011 01:39:44 +0000

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

mjg59 — Mon, 29 Aug 2011 00:32:17 +0000

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.

x86 discoverability is over rated

mjg59 — Mon, 29 Aug 2011 00:28:01 +0000

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

dlang — Sun, 28 Aug 2011 23:57:03 +0000

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

giraffedata — Sun, 28 Aug 2011 23:04:38 +0000

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

mjg59 — Sun, 28 Aug 2011 22:11:45 +0000

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

robbe — Sun, 28 Aug 2011 20:35:26 +0000

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.

Merge into the kernel?

robbe — Sun, 28 Aug 2011 20:17:05 +0000

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/

x86 discoverability is over rated

giraffedata — Sun, 28 Aug 2011 19:18:56 +0000

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

nhippi — Sun, 28 Aug 2011 09:12:10 +0000

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

giraffedata — Sun, 28 Aug 2011 03:33:23 +0000

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?

The udev tail wags the dog

jcm — Sat, 27 Aug 2011 00:47:09 +0000

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.

Merge into the kernel?

jcm — Sat, 27 Aug 2011 00:42:39 +0000

Make sure to merge gnome-shell while you're at it :-)

Linux Plumbers fail

BenHutchings — Thu, 25 Aug 2011 20:11:04 +0000

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.

Linux Plumbers fail

martin.langhoff — Thu, 25 Aug 2011 18:03:50 +0000

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.

The udev tail wags the dog

iabervon — Thu, 25 Aug 2011 17:47:18 +0000

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.

x86 discoverability is over rated

chrispe — Thu, 25 Aug 2011 09:41:19 +0000

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.

The udev tail wags the dog

dilinger — Thu, 25 Aug 2011 04:43:31 +0000

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. :(

http://thread.gmane.org/gmane.linux.drivers.devicetree/7495

Merge into the kernel?

josh — Thu, 25 Aug 2011 02:40:49 +0000

Seems like a perfect candidate.

Merge into the kernel?

cesarb — Thu, 25 Aug 2011 02:36:55 +0000

Perhaps udev could be merged into the kernel, together with perf and kvm? ;-)

The udev tail wags the dog

corbet — Thu, 25 Aug 2011 02:19:01 +0000

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.

The udev tail wags the dog

jonabbey — Thu, 25 Aug 2011 01:46:46 +0000

Neither my Fedora nor my RHEL boxes have a /proc/device-tree file.

Am I missing something?