kay wrote: > 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. so just to be sure i understand your objection: if /proc/device-tree were to move to /sys/device-tree (or similar path, and perhaps be doubly mounted there during a transition period), it would be acceptable to propose that udev start using it? paul > > >> 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 =--------------------- paul fox, pgf@xxxxxxxxxx -- 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
