On Tue, Aug 16, 2011 at 11:34 PM, Kay Sievers <kay.sievers@xxxxxxxx> wrote: > It has to fit into the way /sys is layouted, which is usually very > different from /proc. Right. And the challenge here is that devicetree sits above the kernel's device layer (raising questions on exactly how to represent it in /sys, without creating a container filesystem for /sys itself), where DMI is (hackishly, IMO) exposed as a virtual device (/sys/devices/virtual). Doing the same trick with DT would be bizarre from the kernel standpoint. > 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. Not wanting to criticise any future unified system ideas, I just want to point out that devicetree predates both udev and /sys. It is not new. Your same arguments could be applied to DMI, which is new in comparison, limited in the data it can represent, strangely exposed in the kernel's representation of devices, and platform-specific. Yet DMI and its imperfections already "won" udev, maybe just because of x86 popularity, so I guess that argument is not so interesting. > The fix should be simple enough, we do not look for ACPI tree or the > ARM device tree couterpart, we look for a simple, well-defined > 'machine id' export. That's what class 'dmi' is on x86. Either ARM > exports the same format, or we come up with something new for > everybody which we all swich over to. OK, now I think I understand what you are getting at. A generic sysfs interface that could be fed by either (a part of) DMI or (a very small part of) devicetree, which exposes bare-bones details like vendor and product. That could indeed solve the problem at hand. However, to complicate things further with another item on our TODO list: OLPC offers the same identical laptop models with two alternate keyboards - membrane and mechanical. This is for both x86 and ARM models. At the moment, we use the same keymap for both even despite differences in the keys, but we plan to improve on this in future since it is a bug that keys do not behave according to the symbols printed on them! There is no other difference in the laptop other than the keyboard, so this information could not be captured in the bare-bones info presented in DMI or by the theoretical system mentioned above, unless we were to do something hacky like encode the keyboard model in the product_name. And, you guessed it, info on which type of keyboard is installed comes from a devicetree node. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
