On Tue, Aug 16, 2011 at 20:54, Paul Fox <pgf@xxxxxxxxxx> wrote: > since my initial query was met with such enthusiastic silence :-), Yeah, I guess we all mostly focus on x86 and similar. > i've decided to try another approach. attached is a (very tentative) > patch that supports our non-DMI laptop using a familiy-identifying > attribute found in /proc/device-tree. > > essentially it adds a utility (currently in shell, but which will > trivially turn into C) that facilitates forming environment keys from > device-tree nodes. this is then used in 95-keymap.rules to detect an > XO laptop and apply the right keymap. the device-tree has always been > under /proc on linux -- it would probably make more sense under /sys, > but i'm not sure about the effort needed for, or the ramifications of, > such a move. 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 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. :) 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. I'm very convinced that userspace should not even try to work around platforms that miss proper interfaces which can be used to easily match against system properties. 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
