From: Greg KH <greg@kroah.com>
To: Tim Hockin <thockin@google.com>
Cc: Mike Waychison <mikew@google.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Robert Lippert <rlippert@google.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: SMBIOS / DMI Event Logs in Linux?
Date: Thu, 10 Feb 2011 19:20:49 -0800 [thread overview]
Message-ID: <20110211032049.GB884@kroah.com> (raw)
In-Reply-To: <AANLkTi=tbYj_bonu2i+NHpNY3KUMpsTVT8YDsLhDz_Nm@mail.gmail.com>
On Thu, Feb 10, 2011 at 06:20:52PM -0800, Tim Hockin wrote:
> Caveat: I kind of loathe the proliferation of single use filesystems
> for things that just aren't well mapped to the model.
>
> That said, maybe smbiosfs is not so horrible of a mapping. I'm
> reticent to dredge up my spec, but I think it fits well enough, and
> you can can leave most OEM-specific processing in userspace.
>
> So for the type 15, something like:
>
> /smbios/ # mountpoint
> 15/ # record type (decimal)
> 0/ # instance number (decimal)
> change_token # change token from the type 15 struct
> header # binary dump of the header section (if present)
> 0/ # one dir for each record (decimal)
> id # event ID (decimal)
> id_str # event ID (stringified, if possible)
> size # event size (decimal, bytes)
> timestamp # year, month, day, hour, minute, second
> data # binary dump of the payload
> raw # binary dump of the whole event
>
> This does not handle type descriptors, but I know *we* don't use them..
>
> This does not address operations such as clearing the log or writing a
> new event or locking/unlocking the log. If there's an OEM-specific
> driver loaded it could augment the above.
>
> clear_log # write a number to this to clear some
> percent of the log
> write_events # write a binary dump of an event, including timestamp?
>
> I don't hate it. IT would be cool to have all of SMBIOS available this way.
>
> I'm not sure its worth the work, though. Most Type 15 logs are in
> memory-mapped ROM or in RAM, so tools can access it via /dev/mem (if
> you have privs to do so).
Wait, if this is just a simple "pass through to the hardware", then just
export the thing, with the proper permissions, in a single binary sysfs
file, and do the parsing in userspace.
That would be the simplest thing to do, and fit the rules for valid
sysfs files, and keep people from having to dig through /dev/mem, right?
thanks,
greg k-h
next prev parent reply other threads:[~2011-02-11 3:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-10 23:18 SMBIOS / DMI Event Logs in Linux? Mike Waychison
2011-02-11 1:25 ` Greg KH
2011-02-11 2:19 ` Mike Waychison
2011-02-11 3:19 ` Greg KH
2011-02-11 2:20 ` Tim Hockin
2011-02-11 3:20 ` Greg KH [this message]
[not found] ` <AANLkTin3tu-NiotpzWaQ_ubV0jumb_WsjEK5QGi5w56o@mail.gmail.com>
2011-02-11 18:00 ` Mike Waychison
2011-02-11 18:32 ` Greg KH
2011-02-11 18:56 ` Mike Waychison
2011-02-11 19:12 ` Greg KH
2011-02-11 9:54 ` Alan Cox
2011-02-11 2:04 ` Rob Lippert
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=20110211032049.GB884@kroah.com \
--to=greg@kroah.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=mikew@google.com \
--cc=rlippert@google.com \
--cc=thockin@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox