요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
1
What: /sys/firmware/dmi/entries/
2
Date: February 2011
3
Contact: Mike Waychison <mikew@google.com>
4
Description:
5
Many machines' firmware (x86 and arm64) export DMI /
6
SMBIOS tables to the operating system. Getting at this
7
information is often valuable to userland, especially in
8
cases where there are OEM extensions used.
10
The kernel itself does not rely on the majority of the
11
information in these tables being correct. It equally
12
cannot ensure that the data as exported to userland is
13
without error either.
15
DMI is structured as a large table of entries, where
16
each entry has a common header indicating the type and
17
length of the entry, as well as a firmware-provided
18
'handle' that is supposed to be unique amongst all
19
entries.
21
Some entries are required by the specification, but many
22
others are optional. In general though, users should
23
never expect to find a specific entry type on their
24
system unless they know for certain what their firmware
25
is doing. Machine to machine experiences will vary.
27
Multiple entries of the same type are allowed. In order
28
to handle these duplicate entry types, each entry is
29
assigned by the operating system an 'instance', which is
30
derived from an entry type's ordinal position. That is
31
to say, if there are 'N' multiple entries with the same type
32
'T' in the DMI tables (adjacent or spread apart, it
33
doesn't matter), they will be represented in sysfs as
34
entries "T-0" through "T-(N-1)":
36
Example entry directories::
38
/sys/firmware/dmi/entries/17-0
39
/sys/firmware/dmi/entries/17-1
40
/sys/firmware/dmi/entries/17-2
41
/sys/firmware/dmi/entries/17-3
42
...
44
Instance numbers are used in lieu of the firmware
45
assigned entry handles as the kernel itself makes no
46
guarantees that handles as exported are unique, and
47
there are likely firmware images that get this wrong in
48
the wild.
50
Each DMI entry in sysfs has the common header values
51
exported as attributes:
53
======== =================================================
54
handle The 16bit 'handle' that is assigned to this
55
entry by the firmware. This handle may be
56
referred to by other entries.
57
length The length of the entry, as presented in the
58
entry itself. Note that this is _not the
59
total count of bytes associated with the
60
entry. This value represents the length of
61
the "formatted" portion of the entry. This
62
"formatted" region is sometimes followed by
63
the "unformatted" region composed of nul
64
terminated strings, with termination signalled
65
by a two nul characters in series.
66
raw The raw bytes of the entry. This includes the
67
"formatted" portion of the entry, the
68
"unformatted" strings portion of the entry,
69
and the two terminating nul characters.
70
type The type of the entry. This value is the same
71
as found in the directory name. It indicates
72
how the rest of the entry should be interpreted.
73
instance The instance ordinal of the entry for the
74
given type. This value is the same as found
75
in the parent directory name.
76
position The ordinal position (zero-based) of the entry
77
within the entirety of the DMI entry table.
78
======== =================================================
80
**Entry Specialization**
82
Some entry types may have other information available in
83
sysfs. Not all types are specialized.
85
**Type 15 - System Event Log**
87
This entry allows the firmware to export a log of
88
events the system has taken. This information is
89
typically backed by nvram, but the implementation
90
details are abstracted by this table. This entry's data
91
is exported in the directory::
93
/sys/firmware/dmi/entries/15-0/system_event_log
95
and has the following attributes (documented in the
96
SMBIOS / DMI specification under "System Event Log (Type 15)":
98
- area_length
99
- header_start_offset
100
- data_start_offset
101
- access_method
102
- status
103
- change_token
104
- access_method_address
105
- header_format
106
- per_log_type_descriptor_length
107
- type_descriptors_supported_count
109
As well, the kernel exports the binary attribute:
111
============= ====================================
112
raw_event_log The raw binary bits of the event log
113
as described by the DMI entry.
114
============= ====================================
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
DMI and SMBIOS entry export
1-114| 항목 | 한국어 전문 번역 |
|---|---|
| What | /sys/firmware/dmi/entries/ |
| Date | 2011년 2월 |
| Contact | Mike Waychison <mikew@google.com> |
| Description | 많은 x86·arm64 firmware가 DMI/SMBIOS tables를 OS에 export하며 OEM extensions가 있을 때 userland에서 유용합니다. Kernel은 table 대부분의 정확성에 의존하지 않으며 exported data가 error-free임도 보장하지 않습니다. DMI는 entries의 큰 table이고 각 entry는 type, formatted length와 firmware-provided handle을 가진 common header로 시작합니다. Required entry types도 있지만 많은 types는 optional이므로 firmware behavior를 확실히 알지 못하면 특정 type 존재를 가정하면 안 됩니다. 같은 type의 multiple entries는 허용되며 OS는 type의 ordinal position에서 `instance`를 만들어 N개 type T entries를 `T-0`부터 `T-(N-1)`로 표현합니다. Firmware handles의 uniqueness는 보장되지 않으므로 sysfs naming에는 handles 대신 instances를 사용합니다. 각 entry는 `handle`, formatted portion의 `length`, formatted data·NUL-terminated strings·double-NUL terminator를 모두 포함한 binary `raw`, `type`, per-type `instance`, entire table 안의 zero-based `position`을 export합니다. 일부 entry types는 specialized attributes를 추가합니다. Type 15 System Event Log는 typically NVRAM-backed log를 `15-0/system_event_log` 아래 export하며 `area_length`, `header_start_offset`, `data_start_offset`, `access_method`, `status`, `change_token`, `access_method_address`, `header_format`, `per_log_type_descriptor_length`, `type_descriptors_supported_count`와 binary `raw_event_log`를 제공합니다. |
| Access | Entry directories and binary attributes |
Read DMI entry type T→Find its ordinal among entries of type T→Assign instance 0..N-1→Expose directory T-instance
Firmware table order에서 stable per-type instance directory를 만드는 과정입니다.
AttributeMeaning
handleFirmware-assigned 16-bit reference
lengthFormatted portion length
rawFormatted + strings + double NUL
typeDMI entry type
instancePer-type ordinal
positionZero-based table ordinal
Header, raw payload와 ordering metadata입니다.
GroupAttributes
Offsets and sizearea_length, header_start_offset, data_start_offset
Access and statusaccess_method, status, change_token, access_method_address
Formatheader_format, per_log_type_descriptor_length, type_descriptors_supported_count
Binaryraw_event_log
SMBIOS System Event Log metadata와 raw payload입니다.
/sys/firmware/dmi/entries/17-0
/sys/firmware/dmi/entries/17-1
/sys/firmware/dmi/entries/17-2
/sys/firmware/dmi/entries/17-3
.../sys/firmware/dmi/entries/15-0/system_event_log
Typed instances and raw entry data
sysfs-firmware-dmi-entries:1-114Firmware handles 대신 per-type instances를 directory name에 사용하며 raw는 formatted portion, strings와 double-NUL terminator까지 포함합니다.