All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.