From: Andi Kleen <andi@firstfloor.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Jean Delvare <khali@linux-fr.org>,
Olof Johansson <olof@lixom.net>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH] dmi: export dmi data through debugfs
Date: Thu, 30 Sep 2010 19:34:57 +0200 [thread overview]
Message-ID: <87pqvvuoce.fsf@basil.nowhere.org> (raw)
In-Reply-To: <20100929222804.7f506ba5@lxorguk.ukuu.org.uk> (Alan Cox's message of "Wed, 29 Sep 2010 22:28:04 +0100")
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>> Now if you really insist on exposing the whole DMI table through sysfs,
>> I can't prevent you from doing that. After all, ACPI already exposes
>> its tables under /sys/firmware/acpi/tables (mode 0400). But then you'd
>> rather expose the DMI entry point and tables
>> under /sys/firmware/dmi/tables for consistency, rather than using
>> debugfs. But again, I don't think it is adding any value over what we
>> already have.
>
> If you really the DMI data generally available run dmidecode in the boot
> scripts directed to a file. It even has a dump mode for this.
FWIW i have been pondering to put DMI into sysfs too. One of the reasons
mcelog has to start up as root is that it needs to get these tables
out of /dev/mem.
Just having a binary file to read would be fine though, no need to
do decoding.
-andi
--
ak@linux.intel.com -- Speaking for myself only.
next prev parent reply other threads:[~2010-09-30 17:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-28 21:12 [PATCH] dmi: export dmi data through debugfs Olof Johansson
2010-09-29 7:34 ` Jean Delvare
2010-09-29 14:53 ` Olof Johansson
2010-09-29 15:11 ` Jean Delvare
2010-09-29 21:28 ` Alan Cox
2010-09-30 6:36 ` Jean Delvare
2010-09-30 14:31 ` Olof Johansson
2010-09-30 17:34 ` Andi Kleen [this message]
2010-09-30 17:59 ` Jean Delvare
2010-09-30 15:32 ` Bjorn Helgaas
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=87pqvvuoce.fsf@basil.nowhere.org \
--to=andi@firstfloor.org \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=olof@lixom.net \
--cc=tj@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.