On Mon, 2014-03-17 at 14:56 -0700, Greg KH wrote: > No you can't, sorry. > > And this seems like a huge abuse of sysfs, you better be using binary > sysfs files for your log data... > > Do you have a pointer to where you document this sysfs api in > Documentation/ABI/ ? Yes, the patch adds the documentation along with the facility, I've attached the doc file to this email. This is a wrapper on top of firmware interfaces, in a way we are following ACPI precedent of exposing a bunch of things via sysfs, which also happen to be a simple and very convenient way of doing it. The log itself is a binary attribute in PEL format (or SEL when we support that), we have a userspace parser. > > Now regarding the practicals of sorting out our trees, Stephen suggested > > that rather than doing anything on my side (heh, I like that !), you > > should revert the last patch of the series, the one removing the old > > API, in your tree. > > > > It can then be re-applied later around rc1. > > I'll look to see if we can do that, let me dig it up out of my tree... Thanks. That's how Stephen is fixing it up in -next at the moment. Cheers, Ben. > thanks, > > greg k-h > -- > 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/
What: /sys/firmware/opal/elog Date: Feb 2014 Contact: Stewart Smith <stewart@xxxxxxxxxxxxxxxxxx> Description: This directory exposes error log entries retrieved through the OPAL firmware interface. Each error log is identified by a unique ID and will exist until explicitly acknowledged to firmware. Each log entry has a directory in /sys/firmware/opal/elog. Log entries may be purged by the service processor before retrieved by firmware or retrieved/acknowledged by Linux if there is no room for more log entries. In the event that Linux has retrieved the log entries but not explicitly acknowledged them to firmware and the service processor needs more room for log entries, the only remaining copy of a log message may be in Linux. Typically, a user space daemon will monitor for new entries, read them out and acknowledge them. The service processor may be able to store more log entries than firmware can, so after you acknowledge an event from Linux you may instantly get another one from the queue that was generated some time in the past. The raw log format is a binary format. We currently do not parse this at all in kernel, leaving it up to user space to solve the problem. In future, we may do more parsing in kernel and add more files to make it easier for simple user space processes to extract more information. For each log entry (directory), there are the following files: id: An ASCII representation of the ID of the error log, in hex - e.g. "0x01". type: An ASCII representation of the type id and description of the type of error log. Currently just "0x00 PEL" - platform error log. In the future there may be additional types. raw: A read-only binary file that can be read to get the raw log entry. These are <16kb, often just hundreds of bytes and "average" 2kb. acknowledge: Writing 'ack' to this file will acknowledge the error log to firmware (and in turn the service processor, if applicable). Shortly after acknowledging it, the log entry will be removed from sysfs. Reading this file will list the supported operations (curently just acknowledge).
