On Tue, Aug 16, 2011 at 22:49, Paul Fox <pgf@xxxxxxxxxx> wrote: > 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, It has to fit into the way /sys is layouted, which is usually very different from /proc. > and perhaps be > doubly mounted there during a transition period) No, we also don't accept double mount tricks here. > it would be > acceptable to propose that udev start using it? 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. 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. 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
