Re: keymap rule selection for non-DMI platforms

[Paul Fox <pgf@xxxxxxxxxx>]

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