Message-ID: <20110223015307.13068.14063.stgit@mike.mtv.corp.google.com>
Date:	Tue, 22 Feb 2011 17:53:07 -0800
From:	Mike Waychison <mikew@...gle.com>
To:	Greg KH <greg@...ah.com>, Olof Johansson <olofj@...omium.org>,
	Andi Kleen <andi@...stfloor.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Robert Lippert <rlippert@...gle.com>
Cc:	Jon Mayer <jonmayer@...gle.com>, Tony Luck <tony.luck@...el.com>,
	Duncan Laurie <dlaurie@...gle.com>,
	Aaron Durbin <adurbin@...gle.com>,
	linux-kernel@...r.kernel.org, Tim Hockin <thockin@...gle.com>,
	David Hendrix <dhendrix@...omium.org>,
	linux-api@...r.kernel.org
Subject: [PATCH v2 0/5] Exporting DMI entries via sysfs

This patchset applies to v2.6.38-rc6.

The following series exports information the DMI / SMBIOS tables via
sysfs under the path /sys/firmware/dmi.

For our purposes, we actively use the System Event Log, as described by
DMI entry Type 15.  Currently, we have to grub around /dev/mem to find
this thing, and potentially need to issue IOs directly from userland to
get at the event log, which is suboptimal in terms of security and
architecture.

This series implements the basics needed to iterate through the DMI
entries safely from userland.  Each entry has the handle, the formatted
length and the raw bytes exposed in their own sub-directory under
/sys/firmware/dmi/entries/<type>-<instance>.

As well, this series explodes type 15 as a proof-of-concept of how we
can expose kernel interpretations of the entry data.  For most entries,
there isn't much sense in parsing the entry and exposing each field
as a sysfs attribute as they can be interpreted from userland by
accessing the raw entry itself.  Type 15 however describes an
indirection (pointing at the system event log), and it is generally
useful to export this log in raw form to the user (which requires
interpreting the DMI entry).

This driver relies solely on dmi_walk() for access to the dmi entries.
They are not kept mapped in the "rest" state.  The only bits memo-ized
by the objects in sysfs are the dmi headers, which are used to the find
the entries via dmi_walk on read.   Reading the raw bytes however is
'uncached' by this driver, so that any changes to the entries themselves
are reflected properly by the user-exposed interface.

We intend to use this on our production servers, though it seems to
also be sufficient in suiting Chrome OS's needs
(http://code.google.com/p/chromium-os/issues/detail?id=6795).

Thanks,

Mike Waychison

Related discussions
===================

   - Andi Kleen suggesting that perhaps this data could be exported via
     sysfs:

http://kerneltrap.org/mailarchive/linux-kernel/2010/9/28/4625643/thread

   - Tim Hockin suggesting a potential layout:

https://lkml.org/lkml/2011/2/10/550


Patchset summary
================

firmware: Add DMI entry types to the headers
firmware: Basic dmi-sysfs support
firmware: Break out system_event_log in dmi-sysfs
firmware: Expose DMI type 15 System Event Log
firmware: Add documentation for /sys/firmware/dmi

Diffstat
========

 Documentation/ABI/testing/sysfs-firmware-dmi |  110 ++++
 drivers/firmware/Kconfig                     |   11 
 drivers/firmware/Makefile                    |    1 
 drivers/firmware/dmi-sysfs.c                 |  698 +++++++++++++++++++++++++++
 include/linux/dmi.h                          |   47 +
 5 files changed, 867 insertions(+)

Changelog:
==========
- v2
   - Added 'type', 'instance' and 'position' attributes to each DMI entry.
   - Don't printk KERN_INFO on module load/unload.
   - Default to 'n' for Kconfig.
   - Grammar fixes.
   - Fixed bug reading raw files when multiple instances of the same
     type exist.
- v1
   - Initial public send-out.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists