요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
Log entry metadata, raw payload와 acknowledge
sysfs-firmware-opal-elog:38-62각 unique directory의 id·type·raw를 읽고 ack를 기록하면 firmware와 service processor에 완료를 알린 뒤 sysfs entry가 제거됩니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
What: /sys/firmware/opal/elog
Date: Feb 2014
Contact: Stewart Smith <[email protected]>
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 (currently just acknowledge).
============== ================================================
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
OPAL error-log directory
1-12| 항목 | 내용 |
|---|---|
| What | /sys/firmware/opal/elog |
| Date | 2014년 2월 |
| Contact | Stewart Smith <[email protected]> |
이 directory는 OPAL firmware interface를 통해 회수한 error-log entry를 노출한다. 각 error log는 unique ID로 식별되며 firmware에 명시적으로 acknowledge할 때까지 존재한다. 각 log entry는 /sys/firmware/opal/elog 아래에 별도 directory를 갖는다.
Service-processor 공간과 log 보존 제약
13-36새 log entry를 저장할 공간이 없으면 service processor가 log를 firmware가 회수하기 전 또는 Linux가 회수·acknowledge하기 전에 purge할 수 있다.
Linux가 log entry를 회수했지만 firmware에 아직 acknowledge하지 않았고 service processor가 추가 공간을 필요로 한다면, 해당 log message의 유일한 남은 copy가 Linux 안에 있을 수 있다.
일반적으로 user-space daemon이 새 entry를 감시하고 내용을 읽어 저장한 뒤 acknowledge한다. Service processor는 firmware보다 더 많은 log entry를 저장할 수 있으므로 Linux가 한 event를 acknowledge하면 queue에 오래 대기하던 과거 event가 즉시 새 entry로 나타날 수 있다.
Raw log는 binary format이다. 현재 kernel은 이를 전혀 parse하지 않고 user space에 맡긴다. 앞으로 kernel이 더 많이 parse하고 단순한 user-space process가 정보를 추출하기 쉬운 추가 파일을 만들 수 있다.
Ack는 저장 완료 신호이므로 user-space daemon이 raw payload를 안전하게 보존한 뒤 보내야 한다.
각 error-log entry의 파일
38-62| 파일 | 형식과 동작 |
|---|---|
| id | Error-log ID의 hexadecimal ASCII 표현이다. 예: 0x01. |
| type | Error-log type ID와 description의 ASCII 표현이다. 현재는 platform error log를 뜻하는 0x00 PEL만 사용하지만 앞으로 type이 추가될 수 있다. |
| raw | Raw log entry를 담는 read-only binary file이다. 크기는 16 KiB보다 작고 흔히 수백 byte이며 평균은 약 2 KiB다. |
| acknowledge | ack를 쓰면 firmware와, 해당되는 경우 service processor에 error log를 acknowledge한다. 잠시 뒤 sysfs에서 log entry가 제거된다. 읽으면 지원 operation 목록을 반환하며 현재는 acknowledge만 지원한다. |
Error-log queue와 보존 lifecycle
sysfs-firmware-opal-elog:1-37Firmware와 service processor의 저장 공간이 다르므로 user-space daemon은 새 entry를 감시해 raw log를 영구 저장한 뒤 acknowledge해야 합니다.