Messages in this thread | | | Date | Thu, 10 Feb 2011 18:19:47 -0800 | From | Mike Waychison <> | Subject | Re: SMBIOS / DMI Event Logs in Linux? |
| |
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.
| |