Linux kernel 내부 driver interface가 안정 ABI가 아닌 이유

안정성을 보장하는 interface와 보장하지 않는 interface

Greg Kroah-Hartman이 작성한 이 문서는 Linux에 binary kernel interface도 stable in-kernel interface도 없는 이유를 설명한다.

여기서 말하는 대상은 kernel 내부 interface다. Application이 사용하는 kernel-userspace syscall interface는 시간이 지나도 매우 안정적으로 유지되며 깨지지 않는다. 오래된 kernel을 대상으로 build한 program도 훨씬 새로운 kernel에서 계속 동작한다. User와 application programmer가 안정성을 기대할 수 있는 것은 이 userspace ABI다.

원하는 것은 stable API가 아니라 계속 동작하는 driver

Developer가 원한다고 생각하는 것은 stable kernel interface일 수 있지만 실제로 필요한 것은 계속 build되고 실행되는 stable driver다. 이를 얻는 방법은 driver를 mainline kernel tree에 포함하는 것이다. Main tree 포함은 Linux를 강하고 안정적이며 성숙한 운영체제로 만든 다른 여러 이점도 함께 제공한다.

법적 문제가 아닌 기술적 설명

In-kernel interface 변경을 직접 걱정하는 사람은 kernel driver 작성자 정도다. 대부분의 사용자는 이 interface를 보지도 않고 신경 쓸 필요도 없다.

이 문서는 GPL로 source를 공개하지 않는 closed source, hidden source, binary blob, source wrapper driver의 법적 문제를 다루지 않는다. 법률 문제는 변호사에게 문의해야 하며 여기서는 binary kernel interface와 stable kernel source interface라는 기술적 문제만 설명한다.

Compiler, configuration, architecture가 binary ABI를 바꾼다

• 사용한 C compiler version에 따라 kernel structure alignment와 padding이 달라지고 function이 inline되는 방식도 바뀔 수 있다. Function 배치보다 data structure padding 차이가 특히 중요하다.
• Kernel build option에 따라 같은 structure의 field가 달라지고 일부 function은 아예 구현되지 않을 수 있다. 예를 들어 non-SMP build에서는 일부 lock operation이 아무 code도 만들지 않는다. Memory alignment도 configuration에 따라 달라진다.
• Linux는 매우 다양한 processor architecture에서 실행된다. 한 architecture용 binary driver가 다른 architecture에서 올바르게 동작할 수 없다.

Distribution별 binary module build matrix

특정 distribution의 특정 release와 특정 kernel configuration만 지원한다면 kernel과 정확히 같은 compiler와 configuration으로 module을 build해 일부 문제를 피할 수 있다.

그러나 Linux distribution 수, 각 distribution이 지원하는 release 수, 한 release 안에서 hardware별로 제공하는 여러 kernel flavor를 곱하면 유지해야 할 module build가 폭발적으로 늘어난다. 이런 release 방식을 장기간 지원하는 것은 현실적으로 감당하기 어렵다.

Kernel source interface가 계속 바뀌는 이유

Main kernel tree 밖의 driver를 오래 유지하는 사람에게 stable kernel source interface는 특히 민감한 문제다. Linux kernel 개발은 멈추지 않고 빠르게 진행된다.

Developer가 현재 interface의 bug나 더 나은 설계를 찾으면 interface 자체를 고친다. Function 이름, structure 크기와 field, function parameter가 바뀔 수 있다. 이때 kernel tree 안에서 해당 interface를 사용하는 모든 call site도 같은 변경으로 함께 수정하므로 전체 tree는 계속 올바르게 동작한다.

USB subsystem interface 개편 사례

In-kernel USB interface는 subsystem lifetime 동안 적어도 세 차례 크게 개편되었다.

• Data stream을 synchronous model에서 asynchronous model로 바꾸어 여러 driver의 복잡성을 낮추고 throughput을 높였다. 그 결과 거의 모든 USB device를 가능한 최대 속도에 가깝게 실행할 수 있게 되었다.
• USB driver가 USB core에서 data packet을 allocate하는 방식을 바꾸어 driver가 core에 더 많은 정보를 제공하게 했다. 이를 통해 문서화된 여러 deadlock을 수정했다.

오래된 USB interface까지 계속 유지해야 하는 closed-source 운영체제에서는 새 developer가 낡은 interface를 실수로 사용하고 잘못된 방식으로 code를 작성해 system 안정성을 떨어뜨릴 수 있다.

Linux에 stable source interface 보존 의무가 있었다면 새 interface를 추가하면서 깨진 옛 interface도 계속 유지해야 했다. 이는 자원봉사로 일하는 USB developer에게 아무 이익 없이 추가 작업을 요구하는 결과가 된다.

Security 수정과 unused interface 제거

Security issue가 발견되면 Linux는 매우 빠르게 수정한다. 재발을 막으려면 internal interface 자체를 바꾸어야 할 때가 있고, kernel tree 안의 모든 driver도 동시에 수정한다. Internal interface 변경을 금지하면 이런 보안 문제를 완전하게 고치고 미래의 재발을 막기 어렵다.

Kernel interface는 시간이 지나며 정리된다. 아무도 사용하지 않는 interface는 삭제해 kernel을 가능한 한 작게 유지하고 남은 interface가 실제로 test되도록 한다. 사용자가 없는 interface는 유효성을 현실적으로 시험하기 어렵다.

해결책은 mainline 포함

Main tree 밖의 GPL-compatible Linux driver를 유지하면서 모든 kernel version과 distribution용 binary를 배포하고 변하는 interface를 따라가는 일은 매우 어렵다. 해결책은 driver를 main kernel tree에 포함하는 것이다.

Tree 안의 driver는 kernel interface를 바꾸는 developer가 같은 patch series에서 함께 수정한다. Driver owner가 매번 별도로 따라가지 않아도 driver는 계속 build되고 동작한다.

Main tree driver가 얻는 이점

• 원래 developer의 maintenance cost는 줄고 driver 품질은 높아진다.
• 다른 developer가 feature를 추가한다.
• 다른 사람이 bug를 발견하고 수정한다.
• 다른 사람이 성능 tuning 기회를 찾는다.
• 외부 interface 변경이 필요할 때 다른 developer가 driver를 갱신한다.
• Distribution에 별도 포함 요청을 하지 않아도 driver가 모든 Linux distribution에 자동으로 배포된다.

Linux는 다른 운영체제보다 더 많은 device를 기본 지원하고 더 다양한 processor architecture에서 이를 제공한다. 이는 mainline 중심 개발 model이 실제로 효과가 있음을 보여 준다.

검토 기여

초기 초안을 검토하고 의견을 준 Randy Dunlap, Andrew Morton, David Brownell, Hanna Linder, Robert Love, Nishanth Aravamudan에게 감사를 표한다.