Re: Re: keymap rule selection for non-DMI platforms

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 01/-10/-28163 02:59 PM, Kay Sievers wrote:
> On Tue, Aug 16, 2011 at 23:47, Greg KH <greg@xxxxxxxxx> wrote:
>> On Tue, Aug 16, 2011 at 09:39:37PM +0100, Daniel Drake wrote:
>>> On Tue, Aug 16, 2011 at 9:30 PM, Kay Sievers <kay.sievers@xxxxxxxx> wrote:
>>>> 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.
>>>
>>> You can use it. Just like many platforms (of varying architectures)
>>> already do in other contexts, all using unmodified Linus kernels.
>>>
>>> Device tree is a well-documented cross-platform way of providing
>>> hardware identification information (and in great detail) to the
>>> kernel. I think it is the system you are asking for. Am I right in
>>> saying that its location in /proc is the main downfall that you are
>>> criticising it for? (i.e. would your viewpoint change if it appeared
>>> in /sys tomorrow?)
>>
>> What about all of the existing device tree work that has been going on
>> in the kernel for the past year?  It should be in sysfs already, so why
>> not just use those files instead?
>>
>> As for DMI being "desktop" specific, others agree, and tried to write
>> patches to rename everything.  I think they were rightly shot down as it
>> would have broken lots of userspace code, so there's no problem with
>> putting this type of information into the dmi "namespace" as it is.

That was me.  Thanks Kay for pointing me to this thread.  

The problem with the re-write was that people objected to a unified system interface in which different architecture's firmware could be exposed.  The main issue was that the only two that "really" required this functionality were ia64 and x86.  powerpc *could* make use of the interface but it wasn't a necessity as it is in the ia64 and x86 arches.

> 
> Yeah, we should probably read it as "Digital Machine Identification"
> and just let all platforms export it. Stuff would magically just work
> out-of--the-box. :)
> 

Kay, sometimes the best ideas come from jokes :) ... that doesn't sound as bad as you would think!  Going back to my [v3] here

http://marc.info/?l=linux-kernel&m=131099454831224&w=2

reworking the System Firmware Interface into a Digital Machine Identification layer would

a) resolve Paul's ARM problem discussed in this thread,
b) *DRAMATICALLY* cut down on the size of that patchset.  95% of it is s/DMI/SYSFW/g.

Paul -- what do you think?  If I provided you a clean patchset in the next week or so would you be willing to implement the ARM functionality?  Of course I would be more than willing to help ...

We could push it together and see where that goes.

P.

--
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


[Linux DVB]     [Video Technology]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Devices]     [Fedora Women]     [ALSA Devel]     [Linux USB]

Add to Google Powered by Linux