linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Prarit Bhargava <prarit@redhat.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: Re: keymap rule selection for non-DMI platforms
Date: Tue, 16 Aug 2011 23:35:26 +0000	[thread overview]
Message-ID: <4E4AFEBE.2040601@redhat.com> (raw)
In-Reply-To: <3483.1313087020@foxharp.boston.ma.us>

On 01/-10/-28163 02:59 PM, Kay Sievers wrote:
> On Tue, Aug 16, 2011 at 23:47, Greg KH <greg@kroah.com> 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@vrfy.org> 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\x131099454831224&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.


  parent reply	other threads:[~2011-08-16 23:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-11 18:23 keymap rule selection for non-DMI platforms Paul Fox
2011-08-16 18:54 ` Paul Fox
2011-08-16 19:34 ` Kay Sievers
2011-08-16 20:09 ` Daniel Drake
2011-08-16 20:30 ` Kay Sievers
2011-08-16 20:39 ` Daniel Drake
2011-08-16 20:49 ` Paul Fox
2011-08-16 21:47 ` Greg KH
2011-08-16 22:27 ` Kay Sievers
2011-08-16 22:34 ` Kay Sievers
2011-08-16 22:37 ` Kay Sievers
2011-08-16 22:54 ` Daniel Drake
2011-08-16 23:35 ` Prarit Bhargava [this message]
2011-08-17  2:09 ` Karl O. Pinc
2011-08-17  3:32 ` Paul Fox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E4AFEBE.2040601@redhat.com \
    --to=prarit@redhat.com \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).