All of lore.kernel.org
 help / color / mirror / Atom feed
From: Len Brown <lenb@kernel.org>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Zhang Rui <rui.zhang@intel.com>,
	"Li, Shaohua" <shaohua.li@intel.com>,
	"linux-acpi@vger" <linux-acpi@vger.kernel.org>
Subject: Re: sysfs regression on Supermicro X7DB8+
Date: Thu, 21 Dec 2006 23:51:27 -0500	[thread overview]
Message-ID: <200612212351.27906.lenb@kernel.org> (raw)
In-Reply-To: <200612212110.09190.bjorn.helgaas@hp.com>

On Thursday 21 December 2006 23:10, Bjorn Helgaas wrote:
> On Thursday 21 December 2006 20:12, Zhang Rui wrote:
> > Then I have an idea about the other ones. We can also convert the PNPids
> > reserved in the spec to such kind of strings.
> > E.g.	"PNP0C0D,PNP0C0C,PNP0C0E"	"button"
> > 	"ACPI0003"			"ac_adapter"
> > 	"PNP0C0A"			"battery"
> 
> I hesitate to hide the PNP IDs altogether.  They seem analogous
> to PCI vendor/device IDs.  We expose the PCI IDs directly and
> let user-space map them into human-readable strings.  In fact,
> the mostly-forgotten lspnp package already has a pnp.ids file
> with these mappings.  So I vote for keeping the mapping there.

I agree with Bjorn that it is a slippery slope for the kernel to try to be human friendly,
and that the kernel should just give the raw names and let an application translate them.

I think my original point was somewhat mis-interpreted.
My point is that when the kernel has _no_ PNPid to use to describe the device node
and we have to manufacture a string anyway, that we might as well manufacture
a string that a human can read.

thanks,
-Len

  reply	other threads:[~2006-12-22  4:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-21  8:41 sysfs regression on Supermicro X7DB8+ Len Brown
2006-12-21  9:28 ` Len Brown
2006-12-21  9:50   ` Zhang Rui
2006-12-21 19:54     ` Len Brown
2006-12-22  3:12       ` Zhang Rui
2006-12-22  4:10         ` Bjorn Helgaas
2006-12-22  4:51           ` Len Brown [this message]
2006-12-22  5:09         ` Len Brown

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=200612212351.27906.lenb@kernel.org \
    --to=lenb@kernel.org \
    --cc=bjorn.helgaas@hp.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=shaohua.li@intel.com \
    /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.