Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Kay Sievers <kay.sievers <at> vrfy.org>
Subject: Re: keymap rule selection for non-DMI platforms
Newsgroups: gmane.linux.hotplug.devel
Date: Tuesday 16th August 2011 22:34:31 UTC (over 5 years ago)
On Tue, Aug 16, 2011 at 22:49, Paul Fox  wrote:
> kay wrote:
>  > On Tue, Aug 16, 2011 at 22:09, Daniel Drake  wrote:
>  > > On Tue, Aug 16, 2011 at 8:34 PM, Kay Sievers 
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
CD: 3ms