x86 discoverability is over rated

Posted Aug 28, 2011 9:12 UTC (Sun) by nhippi (subscriber, #34640)
In reply to: x86 discoverability is over rated by giraffedata
Parent article: The udev tail wags the dog

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 (guest, #1954) [Link] (10 responses)

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 (guest, #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] (8 responses)

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 (guest, #1954) [Link] (7 responses)

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 (guest, #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] (4 responses)

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 (guest, #313) [Link] (3 responses)

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] (2 responses)

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 (guest, #313) [Link] (1 responses)

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.