On Tue, Aug 16, 2011 at 22:09, Daniel Drake <dsd@xxxxxxxxxx> wrote: > On Tue, Aug 16, 2011 at 8:34 PM, Kay Sievers <kay.sievers@xxxxxxxx> wrote: >> 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. > > I agree that the use of /proc is strange, but just to make sure you > understand: /proc/device-tree is a standard upstream kernel thing and > has been for a long time. It is not some OLPC-specific oddity to > access our manufacturing data. It is *the* way to access device tree > info on ARM, PPC, SPARC (and x86). And device tree is specifically > built as a way of identifying hardware info which the silicon can't > tell you. udev implementing support for device tree will solve OLPC's > keyboard identification issue, but you'll also solve a whole class of > problems for the wide range of platforms that use device tree (and > those that will soon use it). That might all be true, I don't complain, it's just that udev upstream does not read things like that from /proc, no matter how common the use is. Stuff belongs into /sys/firmware/ /sys/wherever not /proc, and udev can not read things like that from /proc because that would prevent anybody from ever fixing it with the argument that one of the main components relies on it. >> I guess one sensible option is to register the /sys/class/dmi >> interface to ARM too, even when it's not called that way for ARM >> hardware. 'Desktop Management Interface' makes not much sense anyway, >> not even for x86, but hey it's only 3 characters, whatever they mean. >> :) > > I think you're too late to suggest a new solution to this problem. > This is exactly what device tree is for, and Linux has been steadily > going in this direction for a while. Sure, if there is something we all can use, we will switch over to it. Until that happens, hacks have to be maintained by the people relying on them, not by udev upstream. > However, the location inside of /proc is certainly something that can > be criticised. It's just nothing udev will use. Archs can do what they think it's right, and they might be right, I'll not argue here. But userspace should step back working around such things, and people should start working on the 'proper' solution. >> The alternative is to replace /sys/class/dmi with some completely arch >> and platform independent interface and export there what dmi currently >> supports and plug-in the other platforms. > > Device tree is already arch and platform independent, but I'm not sure > how you would make DMI info look like a device tree. Despite both > being able to provide identification info, they are quite different > beasts. Well, then upstream udev will wait for the common solution. :) Kay -- 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
