Firmware Guidelines | Linux 6.18.37

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

요약과 해설

firmware-usage-guidelines.rst:1-49

Firmware update는 새 kernel과 이전 kernel 모두에서 호환성을 유지해야 합니다. Major/minor version과 header metadata로 ABI 변화를 식별하고, 같은 major 안의 compatible update는 최신 file로 교체합니다.

Security fix는 지원되는 firmware major와 stable/LTS kernel patch를 함께 갱신해야 하며, UAPI에 영향을 주는 firmware는 기존 userspace interface와 behavior를 깨뜨려서는 안 됩니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기

1 ===================

2 Firmware Guidelines

3 ===================

5 Users switching to a newer kernel should *not* have to install newer

6 firmware files to keep their hardware working. At the same time updated

7 firmware files must not cause any regressions for users of older kernel

8 releases.

10 Drivers that use firmware from linux-firmware should follow the rules in

11 this guide. (Where there is limited control of the firmware,

12 i.e. company doesn't support Linux, firmwares sourced from misc places,

13 then of course these rules will not apply strictly.)

15 * Firmware files shall be designed in a way that it allows checking for

16 firmware ABI version changes. It is recommended that firmware files be

17 versioned with at least a major/minor version. It is suggested that

18 the firmware files in linux-firmware be named with some device

19 specific name, and just the major version. The firmware version should

20 be stored in the firmware header, or as an exception, as part of the

21 firmware file name, in order to let the driver detact any non-ABI

22 fixes/changes. The firmware files in linux-firmware should be

23 overwritten with the newest compatible major version. Newer major

24 version firmware shall remain compatible with all kernels that load

25 that major number.

27 * If the kernel support for the hardware is normally inactive, or the

28 hardware isn't available for public consumption, this can

29 be ignored, until the first kernel release that enables that hardware.

30 This means no major version bumps without the kernel retaining

31 backwards compatibility for the older major versions. Minor version

32 bumps should not introduce new features that newer kernels depend on

33 non-optionally.

35 * If a security fix needs lockstep firmware and kernel fixes in order to

36 be successful, then all supported major versions in the linux-firmware

37 repo that are required by currently supported stable/LTS kernels,

38 should be updated with the security fix. The kernel patches should

39 detect if the firmware is new enough to declare if the security issue

40 is fixed. All communications around security fixes should point at

41 both the firmware and kernel fixes. If a security fix requires

42 deprecating old major versions, then this should only be done as a

43 last option, and be stated clearly in all communications.

45 * Firmware files that affect the User API (UAPI) shall not introduce

46 changes that break existing userspace programs. Updates to such firmware

47 must ensure backward compatibility with existing userspace applications.

48 This includes maintaining consistent interfaces and behaviors that

49 userspace programs rely on.

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

Firmware 호환성 원칙

1-13

문서 제목은 `Firmware Guidelines`입니다.

사용자가 새 kernel로 전환할 때 hardware를 계속 동작시키기 위해 더 새 firmware file을 설치해야 해서는 안 됩니다. 동시에 업데이트된 firmware file이 이전 kernel release 사용자에게 regression을 일으켜서도 안 됩니다.

`linux-firmware`의 firmware를 사용하는 driver는 이 guide의 규칙을 따라야 합니다. 다만 회사가 Linux를 지원하지 않거나 firmware를 여러 비공식 경로에서 얻는 등 firmware에 대한 통제력이 제한된 경우에는 이 규칙을 엄격히 적용할 수 없습니다.

Firmware ABI versioning

14-25

Firmware file은 firmware ABI version 변경을 확인할 수 있도록 설계해야 합니다. 최소한 major/minor version을 두는 것이 권장됩니다.

`linux-firmware`의 firmware file은 device별 이름과 major version을 조합해 이름을 짓는 방식을 권장합니다. Driver가 non-ABI fix나 변경도 감지할 수 있도록 firmware version은 firmware header에 저장하고, 예외적으로 firmware file name 일부에 저장할 수 있습니다.

`linux-firmware`의 firmware file은 같은 major version에서 가장 새로운 호환 version으로 덮어써야 합니다. 더 새로운 major version firmware는 그 major number를 load하는 모든 kernel과 계속 호환되어야 합니다.

Firmware versioning 규칙

요소권장 규칙

Version 체계최소 major/minor version

File namedevice-specific name + major version

Full version 저장firmware header, 예외적으로 file name

Compatible update같은 major의 최신 file로 덮어쓰기

Major compatibility해당 major를 load하는 모든 kernel과 호환

ABI 변화와 compatible update를 구분하는 naming·storage 정책입니다.

Hardware 공개 전후의 version 정책

26-33

Kernel의 hardware 지원이 보통 비활성 상태이거나 hardware를 일반에 판매하지 않는 동안에는, 해당 hardware를 활성화하는 첫 kernel release가 나오기 전까지 앞의 규칙을 무시할 수 있습니다.

첫 release 이후에는 kernel이 이전 major version과 backward compatibility를 유지하지 않는 한 major version을 올려서는 안 됩니다. Minor version update도 새 kernel이 선택의 여지 없이 의존하는 새 기능을 도입해서는 안 됩니다.

Firmware와 kernel의 security lockstep

34-43

Security fix가 성공하려면 firmware와 kernel fix를 lockstep으로 적용해야 하는 경우, 현재 지원되는 stable/LTS kernel에 필요한 `linux-firmware` repository의 모든 지원 major version을 security fix로 업데이트해야 합니다.

Kernel patch는 firmware가 충분히 새로운지 감지해 security issue가 해결됐는지 선언해야 합니다. Security fix 관련 모든 communication은 firmware fix와 kernel fix를 모두 가리켜야 합니다.

Security fix 때문에 오래된 major version을 폐기해야 한다면 마지막 수단으로만 수행하고, 모든 communication에서 이를 분명하게 밝혀야 합니다.

Lockstep security update

Security issue 식별지원되는 모든 firmware major 수정stable/LTS kernel patch 제공Kernel이 firmware version 충분성 검사Firmware와 kernel fix를 함께 공지구 major 폐기는 마지막 수단으로 명시

지원 중인 firmware major와 stable/LTS kernel fix를 함께 배포·검증하는 흐름입니다.

UAPI backward compatibility

44-49

User API(UAPI)에 영향을 주는 firmware file은 기존 userspace program을 깨뜨리는 변경을 도입해서는 안 됩니다.

이런 firmware update는 기존 userspace application과 backward compatibility를 보장해야 하며, userspace program이 의존하는 interface와 behavior를 일관되게 유지해야 합니다.

Firmware compatibility 대상

대상보장

이전 kernel새 firmware update로 regression이 없어야 함

새 kernel기존 compatible firmware로 hardware가 계속 동작해야 함

기존 userspaceUAPI interface와 behavior를 유지해야 함

Kernel과 userspace 양쪽에서 유지해야 할 compatibility 계약입니다.