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
> > >> Reading such things from /proc is kinda taboo from code we
> > >> udev. All things not related to processes really do not belong
> > >> /proc and udev code should never get into the way of possibly
> > >> deprecating these things in the long run, even when they might
> > >> 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
> > >> 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
> > > 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
> > > 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
> > > keyboard identification issue, but you'll also solve a whole class
> > > 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
> > 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.
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