| |||||||||||||
x86 discoverability is over ratedx86 discoverability is over ratedPosted Aug 28, 2011 23:04 UTC (Sun) by giraffedata (subscriber, #1954)In reply to: x86 discoverability is over rated by mjg59 Parent article: The udev tail wags the dog 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.
(Log in to post comments)
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.
|
|||||||||||||