요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
============
Devlink Info
============
The ``devlink-info`` mechanism enables device drivers to report device
(hardware and firmware) information in a standard, extensible fashion.
The original motivation for the ``devlink-info`` API was twofold:
- making it possible to automate device and firmware management in a fleet
of machines in a vendor-independent fashion (see also
:ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`);
- name the per component FW versions (as opposed to the crowded ethtool
version string).
``devlink-info`` supports reporting multiple types of objects. Reporting driver
versions is generally discouraged - here, and via any other Linux API.
.. list-table:: List of top level info objects
:widths: 5 95
* - Name
- Description
* - ``driver``
- Name of the currently used device driver, also available through sysfs.
* - ``serial_number``
- Serial number of the device.
This is usually the serial number of the ASIC, also often available
in PCI config space of the device in the *Device Serial Number*
capability.
The serial number should be unique per physical device.
Sometimes the serial number of the device is only 48 bits long (the
length of the Ethernet MAC address), and since PCI DSN is 64 bits long
devices pad or encode additional information into the serial number.
One example is adding port ID or PCI interface ID in the extra two bytes.
Drivers should make sure to strip or normalize any such padding
or interface ID, and report only the part of the serial number
which uniquely identifies the hardware. In other words serial number
reported for two ports of the same device or on two hosts of
a multi-host device should be identical.
* - ``board.serial_number``
- Board serial number of the device.
This is usually the serial number of the board, often available in
PCI *Vital Product Data*.
* - ``fixed``
- Group for hardware identifiers, and versions of components
which are not field-updatable.
Versions in this section identify the device design. For example,
component identifiers or the board version reported in the PCI VPD.
Data in ``devlink-info`` should be broken into the smallest logical
components, e.g. PCI VPD may concatenate various information
to form the Part Number string, while in ``devlink-info`` all parts
should be reported as separate items.
This group must not contain any frequently changing identifiers,
such as serial numbers. See
:ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`
to understand why.
* - ``running``
- Group for information about currently running software/firmware.
These versions often only update after a reboot, sometimes device reset.
* - ``stored``
- Group for software/firmware versions in device flash.
Stored values must update to reflect changes in the flash even
if reboot has not yet occurred. If device is not capable of updating
``stored`` versions when new software is flashed, it must not report
them.
Each version can be reported at most once in each version group. Firmware
components stored on the flash should feature in both the ``running`` and
``stored`` sections, if device is capable of reporting ``stored`` versions
(see :ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`).
In case software/firmware components are loaded from the disk (e.g.
``/lib/firmware``) only the running version should be reported via
the kernel API.
Please note that any security versions reported via devlink are purely
informational. Devlink does not use a secure channel to communicate with
the device.
Generic Versions
================
It is expected that drivers use the following generic names for exporting
version information. If a generic name for a given component doesn't exist yet,
driver authors should consult existing driver-specific versions and attempt
reuse. As last resort, if a component is truly unique, using driver-specific
names is allowed, but these should be documented in the driver-specific file.
All versions should try to use the following terminology:
.. list-table:: List of common version suffixes
:widths: 10 90
* - Name
- Description
* - ``id``, ``revision``
- Identifiers of designs and revision, mostly used for hardware versions.
* - ``api``
- Version of API between components. API items are usually of limited
value to the user, and can be inferred from other versions by the vendor,
so adding API versions is generally discouraged as noise.
* - ``bundle_id``
- Identifier of a distribution package which was flashed onto the device.
This is an attribute of a firmware package which covers multiple versions
for ease of managing firmware images (see
:ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`).
``bundle_id`` can appear in both ``running`` and ``stored`` versions,
but it must not be reported if any of the components covered by the
``bundle_id`` was changed and no longer matches the version from
the bundle.
board.id
--------
Unique identifier of the board design.
board.rev
---------
Board design revision.
asic.id
-------
ASIC design identifier.
asic.rev
--------
ASIC design revision/stepping.
board.manufacture
-----------------
An identifier of the company or the facility which produced the part.
board.part_number
-----------------
Part number of the board and its components.
fw
--
Overall firmware version, often representing the collection of
fw.mgmt, fw.app, etc.
fw.mgmt
-------
Control unit firmware version. This firmware is responsible for house
keeping tasks, PHY control etc. but not the packet-by-packet data path
operation.
fw.mgmt.api
-----------
Firmware interface specification version of the software interfaces between
driver and firmware.
fw.app
------
Data path microcode controlling high-speed packet processing.
fw.undi
-------
UNDI software, may include the UEFI driver, firmware or both.
fw.ncsi
-------
Version of the software responsible for supporting/handling the
Network Controller Sideband Interface.
fw.psid
-------
Unique identifier of the firmware parameter set. These are usually
parameters of a particular board, defined at manufacturing time.
fw.roce
-------
RoCE firmware version which is responsible for handling roce
management.
fw.bundle_id
------------
Unique identifier of the entire firmware bundle.
fw.bootloader
-------------
Version of the bootloader.
Future work
===========
The following extensions could be useful:
- on-disk firmware file names - drivers list the file names of firmware they
may need to load onto devices via the ``MODULE_FIRMWARE()`` macro. These,
however, are per module, rather than per device. It'd be useful to list
the names of firmware files the driver will try to load for a given device,
in order of priority.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Devlink Info 소개
1-20이 문서는 `GPL-2.0-only OR BSD-2-Clause` 이중 라이선스를 따릅니다.
Devlink Info
`devlink-info` mechanism을 사용하면 장치 driver가 hardware와 firmware 정보를 표준화되고 확장 가능한 방식으로 보고할 수 있습니다.
`devlink-info` API의 원래 목적은 두 가지였습니다.
- 여러 machine으로 구성된 fleet에서 vendor에 종속되지 않는 장치·firmware 관리를 자동화합니다. `Documentation/networking/devlink/devlink-flash.rst`도 참조하십시오.
- 복잡하게 몰려 있는 ethtool version string 대신 component별 firmware version에 이름을 부여합니다.
`devlink-info`는 여러 object type의 보고를 지원합니다. 이 API를 포함해 Linux API로 driver version 자체를 보고하는 것은 일반적으로 권장하지 않습니다.
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
============
Devlink Info
============
The ``devlink-info`` mechanism enables device drivers to report device
(hardware and firmware) information in a standard, extensible fashion.
The original motivation for the ``devlink-info`` API was twofold:
- making it possible to automate device and firmware management in a fleet
of machines in a vendor-independent fashion (see also
:ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`);
- name the per component FW versions (as opposed to the crowded ethtool
version string).
``devlink-info`` supports reporting multiple types of objects. Reporting driver
versions is generally discouraged - here, and via any other Linux API.
최상위 info object와 version group
21-92최상위 info object는 다음과 같습니다.
driver·장치 식별 정보와 hardware 및 firmware version group을 구분합니다.
`serial_number`는 보통 ASIC serial number이며 PCI configuration space의 Device Serial Number capability에도 흔히 있습니다. 물리 장치마다 고유해야 합니다.
장치 serial number가 Ethernet MAC address 길이인 48bit뿐인 경우가 있습니다. PCI DSN은 64bit이므로 장치는 남은 2byte에 padding 또는 port ID, PCI interface ID 같은 추가 정보를 encoding할 수 있습니다.
driver는 이런 padding이나 interface ID를 제거 또는 정규화하고 hardware를 고유하게 식별하는 부분만 보고해야 합니다. 같은 장치의 두 port나 multi-host 장치의 두 host에서 보고한 serial number는 같아야 합니다.
`board.serial_number`는 board serial number이며 PCI Vital Product Data에 있는 경우가 많습니다.
`fixed` group은 hardware 식별자와 현장에서 갱신할 수 없는 component version을 담습니다. component identifier나 PCI VPD가 보고하는 board version처럼 장치 설계를 식별하는 정보입니다.
`devlink-info` 데이터는 가장 작은 논리 component로 나눠야 합니다. 예를 들어 PCI VPD가 여러 정보를 연결해 Part Number string을 만들더라도 `devlink-info`에서는 각 부분을 별도 item으로 보고해야 합니다.
`fixed`에는 serial number처럼 자주 달라지는 식별자를 넣으면 안 됩니다. 이유는 `Documentation/networking/devlink/devlink-flash.rst`를 참조하십시오.
`running`은 현재 실행 중인 software·firmware 정보를 담고, 이 값은 흔히 reboot 또는 device reset 뒤에만 갱신됩니다.
`stored`는 장치 flash의 software·firmware version을 담습니다. 아직 reboot하지 않았더라도 flash가 바뀌면 stored 값도 그 변화를 반영해야 합니다. 새 software를 flash했을 때 stored version을 갱신할 수 없는 장치는 이를 보고하면 안 됩니다.
각 version은 version group마다 최대 한 번 보고할 수 있습니다. flash에 저장된 firmware component는 장치가 stored version을 보고할 수 있다면 `running`과 `stored` 양쪽에 나타나야 합니다.
`/lib/firmware` 같은 disk에서 loading한 software·firmware component는 kernel API를 통해 `running` version만 보고해야 합니다.
devlink가 보고하는 security version은 정보 제공용일 뿐입니다. devlink는 장치와 통신할 때 secure channel을 사용하지 않습니다.
.. list-table:: List of top level info objects
:widths: 5 95
* - Name
- Description
* - ``driver``
- Name of the currently used device driver, also available through sysfs.
* - ``serial_number``
- Serial number of the device.
This is usually the serial number of the ASIC, also often available
in PCI config space of the device in the *Device Serial Number*
capability.
The serial number should be unique per physical device.
Sometimes the serial number of the device is only 48 bits long (the
length of the Ethernet MAC address), and since PCI DSN is 64 bits long
devices pad or encode additional information into the serial number.
One example is adding port ID or PCI interface ID in the extra two bytes.
Drivers should make sure to strip or normalize any such padding
or interface ID, and report only the part of the serial number
which uniquely identifies the hardware. In other words serial number
reported for two ports of the same device or on two hosts of
a multi-host device should be identical.
* - ``board.serial_number``
- Board serial number of the device.
This is usually the serial number of the board, often available in
PCI *Vital Product Data*.
* - ``fixed``
- Group for hardware identifiers, and versions of components
which are not field-updatable.
Versions in this section identify the device design. For example,
component identifiers or the board version reported in the PCI VPD.
Data in ``devlink-info`` should be broken into the smallest logical
components, e.g. PCI VPD may concatenate various information
to form the Part Number string, while in ``devlink-info`` all parts
should be reported as separate items.
This group must not contain any frequently changing identifiers,
such as serial numbers. See
:ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`
to understand why.
* - ``running``
- Group for information about currently running software/firmware.
These versions often only update after a reboot, sometimes device reset.
* - ``stored``
- Group for software/firmware versions in device flash.
Stored values must update to reflect changes in the flash even
if reboot has not yet occurred. If device is not capable of updating
``stored`` versions when new software is flashed, it must not report
them.
Each version can be reported at most once in each version group. Firmware
components stored on the flash should feature in both the ``running`` and
``stored`` sections, if device is capable of reporting ``stored`` versions
(see :ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`).
In case software/firmware components are loaded from the disk (e.g.
``/lib/firmware``) only the running version should be reported via
the kernel API.
Please note that any security versions reported via devlink are purely
informational. Devlink does not use a secure channel to communicate with
the device.
공통 version 이름과 suffix
93-127공통 version
driver는 version 정보를 내보낼 때 다음 공통 이름을 사용해야 합니다. component에 맞는 공통 이름이 아직 없다면 기존 driver 전용 version을 살펴보고 재사용을 시도해야 합니다.
component가 정말 고유한 경우에만 최후 수단으로 driver 전용 이름을 사용할 수 있으며, 그 이름은 driver 전용 문서에 기록해야 합니다.
모든 version은 다음 용어를 사용하도록 노력해야 합니다.
hardware 설계, component API, firmware package를 표현하는 공통 용어입니다.
`bundle_id`는 `running`과 `stored` version 모두에 나타날 수 있습니다. 다만 bundle이 포괄하는 component 중 하나라도 바뀌어 bundle version과 더 이상 일치하지 않으면 보고해서는 안 됩니다.
Generic Versions
================
It is expected that drivers use the following generic names for exporting
version information. If a generic name for a given component doesn't exist yet,
driver authors should consult existing driver-specific versions and attempt
reuse. As last resort, if a component is truly unique, using driver-specific
names is allowed, but these should be documented in the driver-specific file.
All versions should try to use the following terminology:
.. list-table:: List of common version suffixes
:widths: 10 90
* - Name
- Description
* - ``id``, ``revision``
- Identifiers of designs and revision, mostly used for hardware versions.
* - ``api``
- Version of API between components. API items are usually of limited
value to the user, and can be inferred from other versions by the vendor,
so adding API versions is generally discouraged as noise.
* - ``bundle_id``
- Identifier of a distribution package which was flashed onto the device.
This is an attribute of a firmware package which covers multiple versions
for ease of managing firmware images (see
:ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`).
``bundle_id`` can appear in both ``running`` and ``stored`` versions,
but it must not be reported if any of the components covered by the
``bundle_id`` was changed and no longer matches the version from
the bundle.
공통 hardware·firmware version
128-214board와 ASIC 식별 정보, firmware component별 version의 표준 이름입니다.
board.id
--------
Unique identifier of the board design.
board.rev
---------
Board design revision.
asic.id
-------
ASIC design identifier.
asic.rev
--------
ASIC design revision/stepping.
board.manufacture
-----------------
An identifier of the company or the facility which produced the part.
board.part_number
-----------------
Part number of the board and its components.
fw
--
Overall firmware version, often representing the collection of
fw.mgmt, fw.app, etc.
fw.mgmt
-------
Control unit firmware version. This firmware is responsible for house
keeping tasks, PHY control etc. but not the packet-by-packet data path
operation.
fw.mgmt.api
-----------
Firmware interface specification version of the software interfaces between
driver and firmware.
fw.app
------
Data path microcode controlling high-speed packet processing.
fw.undi
-------
UNDI software, may include the UEFI driver, firmware or both.
fw.ncsi
-------
Version of the software responsible for supporting/handling the
Network Controller Sideband Interface.
fw.psid
-------
Unique identifier of the firmware parameter set. These are usually
parameters of a particular board, defined at manufacturing time.
fw.roce
-------
RoCE firmware version which is responsible for handling roce
management.
fw.bundle_id
------------
Unique identifier of the entire firmware bundle.
fw.bootloader
-------------
Version of the bootloader.
향후 확장
215-224향후 작업
다음 확장이 유용할 수 있습니다.
disk firmware file 이름을 장치별로 보고하는 기능입니다. 현재 driver는 `MODULE_FIRMWARE()` macro로 장치에 loading할 수 있는 firmware file 이름을 나열하지만, 이 정보는 장치별이 아니라 module별입니다.
특정 장치에 대해 driver가 loading을 시도할 firmware file 이름을 priority 순서대로 나열할 수 있다면 유용합니다.
Future work
===========
The following extensions could be useful:
- on-disk firmware file names - drivers list the file names of firmware they
may need to load onto devices via the ``MODULE_FIRMWARE()`` macro. These,
however, are per module, rather than per device. It'd be useful to list
the names of firmware files the driver will try to load for a given device,
in order of priority.
요약·해설
devlink-info.rst:1-224`devlink-info`는 fleet 관리 도구가 vendor와 무관하게 hardware 설계와 firmware 상태를 비교할 수 있도록 정보를 정규화합니다. `fixed`는 설계, `running`은 현재 실행 상태, `stored`는 다음 reset 뒤 적용될 flash 상태를 나타내며 serial number와 security version의 한계를 명확히 구분합니다.
변경 빈도와 적용 시점에 따라 version group을 구분합니다.