On Tue, Aug 16, 2011 at 20:54, Paul Fox 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.
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html