SMBIOS / DMI Event Logs in Linux?
Mike Waychison
I need some guidance. Do either of you know of any attempts to have the
kernel decode and display/interact with DMI type 15: System Event Log?
The event log I'm dealing with while cleaning up the "gsmi" driver
interacts with a log that is modeled after the System Event Log. I'm
wondering if there is any precedent for a clean way to expose the event
log, I'd like to use it (replacing the ioctls from my earlier patch
series send-out).
FYI, we use OEM specific headers and descriptors, which probably doesn't
help.
Do most folks that need access to this data rely on /dev/mem and
dmidecode? I'd like to avoid going that route if possible.
Lacking any better ideas though, I was thinking of something along the
lines of the following:
$ cat /sys/firmware/gsmi/eventlog
<offset> <boot number> <recorded time> <quoted reason> <optional data>
...
with a single event log entry per line.
<offset> would be the record number,
<boot number> is the recorded boot number
<recorded time> comes from each record,
<quoted reason> is the English translation of Event Log Types from
the DMTF standard + vendor extended types we use.
<optional data> is space separated values associated with <quoted reason>
We also have a interfaces for clearing a fraction of the log, which I'm
thinking is probably best expressed as a value of 0 through 100 written
to a file, maybe /sys/firmware/gsmi/clear_eventlog ?
As well, we need to export to userland a way to append data to the log.
I was thinking we could write a parser to take in an entry and ensure
it is well-formatted, but I'm a little hesitant to go this route as our
records embed a timestamp, which I'd rather not have to figure out from
within the kernel. Perhaps a raw (binary) interface to write records to
the log would suffice? /sys/firmware/gsmi/append_to_eventlog ?
If so, does /sys/firmware/gsmi/raw_eventlog make sense too?
Thanks,
Mike Waychison
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greg KH
> Hey guys,
>
> I need some guidance. Do either of you know of any attempts to have
> the kernel decode and display/interact with DMI type 15: System
> Event Log?
I don't have any experience in this area, but I do have one comment on
your proposal below:
> The event log I'm dealing with while cleaning up the "gsmi" driver
> interacts with a log that is modeled after the System Event Log.
> I'm wondering if there is any precedent for a clean way to expose
> the event log, I'd like to use it (replacing the ioctls from my
> earlier patch series send-out).
>
> FYI, we use OEM specific headers and descriptors, which probably
> doesn't help.
>
> Do most folks that need access to this data rely on /dev/mem and
> dmidecode? I'd like to avoid going that route if possible.
>
> Lacking any better ideas though, I was thinking of something along
> the lines of the following:
>
>
> $ cat /sys/firmware/gsmi/eventlog
> <offset> <boot number> <recorded time> <quoted reason> <optional data>
> ...
>
> with a single event log entry per line.
> <offset> would be the record number,
> <boot number> is the recorded boot number
> <recorded time> comes from each record,
> <quoted reason> is the English translation of Event Log Types from
> the DMTF standard + vendor extended types we use.
> <optional data> is space separated values associated with <quoted reason>
Ick, no, remember, sysfs is "one value per file". doing even a single
line like you describe here isn't ok, not to mention a huge buffer of
these lines.
And no, a "binary" sysfs file is not ok either.
Now your idea for such a log file is fine, I'm not saying that's not ok,
or acceptable, just don't put it in sysfs, sorry. Try using the ring
buffer framework from the tracing code perhaps?
Or use debugfs? Or make a 'firmwarefs'? I can easily knock that
together if you need it.
thanks,
greg k-h
Rob Lippert
> Hey guys,
>
> I need some guidance. Do either of you know of any attempts to have the
> kernel decode and display/interact with DMI type 15: System Event Log?
>
I don't know what the benefit of the having the kernel decode the SEL
would be besides the ability to printk() the contents during boot
time.
Since it generally contains vendor/OEM/machine specific data having to
have each vendor provide their own kernel module to decode seems like
a maintenance pain. Also having the decoding in the kernel means that
adding any new event types requires respinning a kernel.
> The event log I'm dealing with while cleaning up the "gsmi" driver interacts
> with a log that is modeled after the System Event Log. �I'm wondering if
> there is any precedent for a clean way to expose the event log, I'd like to
> use it (replacing the ioctls from my earlier patch series send-out).
>
> FYI, we use OEM specific headers and descriptors, which probably doesn't
> help.
>
> Do most folks that need access to this data rely on /dev/mem and dmidecode?
> �I'd like to avoid going that route if possible.
>
> Lacking any better ideas though, I was thinking of something along the lines
> of the following:
>
>
> $ cat /sys/firmware/gsmi/eventlog
> <offset> <boot number> <recorded time> <quoted reason> <optional data>
> ...
>
> with a single event log entry per line.
> �<offset> would be the record number,
> �<boot number> is the recorded boot number
> �<recorded time> comes from each record,
> �<quoted reason> is the English translation of Event Log Types from the DMTF
> standard + vendor extended types we use.
> �<optional data> is space separated values associated with <quoted reason>
>
What about just exposing the "raw" bytes of the eventlog similar to
how the kernel currently exposes the ACPI tables at e.g.:
/sys/firmware/acpi/tables/DSDT
That would avoid the userspace app having to do the mmio or port io to
actually read the eventlog and the kernel can export it in a standard
fashion on any machine which supports an SMBIOS-style event log table.
> We also have a interfaces for clearing a fraction of the log, which I'm
> thinking is probably best expressed as a value of 0 through 100 written to a
> file, maybe /sys/firmware/gsmi/clear_eventlog ?
>
This is definitely a vendor-specific extension as I know some other
eventlog interfaces (like IPMI) support things like deleting
individual entries.
> As well, we need to export to userland a way to append data to the log. �I
> was thinking we could write a parser to take in an entry and ensure it is
> well-formatted, but I'm a little hesitant to go this route as our records
> embed a timestamp, which I'd rather not have to figure out from within the
> kernel. �Perhaps a raw (binary) interface to write records to the log would
> suffice? �/sys/firmware/gsmi/append_to_eventlog ?
>
Verification of the data is probably best left to the
BIOS/BMC/whatever that is storing the event data and that can return
an error back to userspace if a record is invalid. Otherwise you're
again potentially duplicating the parsing/verifying work that is
already being done in userspace and the BIOS.
Mike Waychison
Works fine for the /sys/firmware/efi stuff. Works well enough for
/sys/firmware/acpi too.
>
> Now your idea for such a log file is fine, I'm not saying that's not ok,
> or acceptable, just don't put it in sysfs, sorry. Try using the ring
> buffer framework from the tracing code perhaps?
>
> Or use debugfs? Or make a 'firmwarefs'? I can easily knock that
> together if you need it.
Are you seriously asking for another filesystem?
I don't get why you're holding me to these standards that that are
totally missed by these same subsystems that you maintain.
Tim Hockin
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). I thought the SMI ioctl() interface worked
just fine for logging and clearing. And hell, we could do that from
userspace if we had to, it's just IO ports, I think. Maybe you need a
userspace V-to-P translation, too.
Tim
Greg KH
Do any of those files have multiple lines? I don't have a system here
that has that directory.
> Works well enough for /sys/firmware/acpi too.
Those all look to be "one value per file" as well.
I don't see any long logs in these firmware types, or am I missing
something?
> >Now your idea for such a log file is fine, I'm not saying that's not ok,
> >or acceptable, just don't put it in sysfs, sorry. Try using the ring
> >buffer framework from the tracing code perhaps?
> >
> >Or use debugfs? Or make a 'firmwarefs'? I can easily knock that
> >together if you need it.
>
> Are you seriously asking for another filesystem?
What's to be afraid of another filesystem? It's only 250 lines of code,
and trivial to create.
Remember, sysfs almost was a filesystem-per-device implementation, as
our superblock and mounting logic is very nice and easy to handle all
race conditions. I objected to that as it would be a bit unwieldy for
some filesystem mount lists, but the idea is still quite sane and
reasonable.
And also, a filesystem-per-type is just fine. It uniquely keeps things
separate, and defines interfaces properly.
> I don't get why you're holding me to these standards that that are
> totally missed by these same subsystems that you maintain.
I do not see any files in the subsystems I maintain that have multiple
values per lines, and have multiple lines, in sysfs files. What have I
missed that you are noticing?
thanks,
greg k-h
Greg KH
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?
Alan Cox
> or acceptable, just don't put it in sysfs, sorry. Try using the ring
> buffer framework from the tracing code perhaps?
Thats probably overkill unless you need to field messages very fast and
synchronize them with other trace data (in which case it's probably not
overkill)
> Or use debugfs? Or make a 'firmwarefs'? I can easily knock that
> together if you need it.
netlink, connector, or even just a simple misc device that tosses them
down a kfifo ?
Alan
Mike Waychison
On Thu, Feb 10, 2011 at 7:20 PM, Greg KH <gr...@kroah.com> wrote:
> 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.
>
If you mean s/hardware/firmware/, then yes.
>
> 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?
Yup, exposing the log via a bin_attribute and allowing for blobs to be
appended (with the firmware either accepting or rejecting the format
will do).
Greg KH
> resend as plain text, sorry :(
>
>
> On Thu, Feb 10, 2011 at 7:20 PM, Greg KH <gr...@kroah.com> wrote:
> > 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.
> >
>
> If you mean s/hardware/firmware/, then yes.
Yes, sorry, that is what I ment.
> > 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?
>
> Yup, exposing the log via a bin_attribute and allowing for blobs to be
> appended (with the firmware either accepting or rejecting the format
> will do).
Great, that should be a simple thing to do then, right?
greg k-h
Mike Waychison
> On Fri, Feb 11, 2011 at 10:00:37AM -0800, Mike Waychison wrote:
>> resend as plain text, sorry :(
>>
>>
>> On Thu, Feb 10, 2011 at 7:20 PM, Greg KH <gr...@kroah.com> wrote:
>> > 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.
>> >
>>
>> If you mean s/hardware/firmware/, then yes.
>
> Yes, sorry, that is what I ment.
>
>> > 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?
>>
>> Yup, exposing the log via a bin_attribute and allowing for blobs to be
>> appended (with the firmware either accepting or rejecting the format
>> will do).
>
> Great, that should be a simple thing to do then, right?
Ya. Here's what I'm working on now:
/sys/firmware/gsmi/eventlog
- read: reads out binary bytes of the log as exported by firmware.
- write: takes the user buffer and passes it on to the firmware via
a SET_EVENT_LOG command and returns a mapped errno to the user.
/sys/firmware/gsmi/clear_eventlog
- write-only: takes a value between 0 and 100 and passes it to the
firmware to clear out a percentage of the log.
/sys/firmware/gsmi/clear_config
- write-only: takes arbitrary data and tells the firmware to wipe it's config.
/sys/firmware/gsmi/vars (directory)
- same code as /sys/firmware/efi/vars except firmware calls vector
through gsmi instead of the EFI runtime services page (I've
abstracted it out for re-use)
This covers the gsmi driver and removes the ioctls completely from it.
I've already changed the "memconsole" driver I sent out a while ago to
export itself as an untouched binary file /sys/firmware/log .
The only bit that remains that needs cleaning is the 'bootlog' driver.
I'm going to work with Robert offline (or online if he wants to
follow up here) with what "proper" kernel interfaces should look like
for his purposes.
Greg KH
Wonderful, that should have hopefully also made the code cleaner.
> I've already changed the "memconsole" driver I sent out a while ago to
> export itself as an untouched binary file /sys/firmware/log .
>
> The only bit that remains that needs cleaning is the 'bootlog' driver.
> I'm going to work with Robert offline (or online if he wants to
> follow up here) with what "proper" kernel interfaces should look like
> for his purposes.
I thought that it was agreed that it too would be a binary sysfs file to
be read from? Or was that me just wishing it would be so? :)
thanks,
greg k-h