Re: SMBIOS / DMI Event Logs in Linux?

[Mike Waychison]

On 02/10/11 17:25, Greg KH wrote:
> On Thu, Feb 10, 2011 at 03:18:14PM -0800, Mike Waychison wrote:
> > 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.

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/