The Linux kernel driver interface

안정성을 보장하는 userspace ABI

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다.

.. include:: ../disclaimer-ita.rst

:Original: :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>`
:Translator: Federico Vaga <[email protected]>

.. _it_stable_api_nonsense:

L'interfaccia dei driver per il kernel Linux
============================================

(tutte le risposte alle vostre domande e altro)

Greg Kroah-Hartman <[email protected]>

Questo è stato scritto per cercare di spiegare perché Linux **non ha
un'interfaccia binaria, e non ha nemmeno un'interfaccia stabile**.

.. note::

   Questo articolo parla di interfacce **interne al kernel**, non delle
   interfacce verso lo spazio utente.

   L'interfaccia del kernel verso lo spazio utente è quella usata dai
   programmi, ovvero le chiamate di sistema.  Queste interfacce sono **molto**
   stabili nel tempo e non verranno modificate.  Ho vecchi programmi che sono
   stati compilati su un kernel 0.9 (circa) e tuttora funzionano sulle versioni
   2.6 del kernel.  Queste interfacce sono quelle che gli utenti e i
   programmatori possono considerare stabili.

Stable API가 아니라 계속 동작하는 driver

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

Riepilogo generale
------------------

Pensate di volere un'interfaccia del kernel stabile, ma in realtà non la
volete, e nemmeno sapete di non volerla.  Quello che volete è un driver
stabile che funzioni, e questo può essere ottenuto solo se il driver si trova
nei sorgenti del kernel.  Ci sono altri vantaggi nell'avere il proprio driver
nei sorgenti del kernel, ognuno dei quali hanno reso Linux un sistema operativo
robusto, stabile e maturo; questi sono anche i motivi per cui avete scelto
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라는 기술적 문제만 설명한다.

Introduzione
------------

Solo le persone un po' strambe vorrebbero scrivere driver per il kernel con
la costante preoccupazione per i cambiamenti alle interfacce interne.  Per il
resto del mondo, queste interfacce sono invisibili o non di particolare
interesse.

Innanzitutto, non tratterò **alcun** problema legale riguardante codice
chiuso, nascosto, avvolto, blocchi binari, o qualsia altra cosa che descrive
driver che non hanno i propri sorgenti rilasciati con licenza GPL.  Per favore
fate riferimento ad un avvocato per qualsiasi questione legale, io sono un
programmatore e perciò qui vi parlerò soltanto delle questioni tecniche (non
per essere superficiali sui problemi legali, sono veri e dovete esserne a
conoscenza in ogni circostanza).

Dunque, ci sono due tematiche principali: interfacce binarie del kernel e
interfacce stabili nei sorgenti.  Ognuna dipende dall'altra, ma discuteremo
prima delle cose binarie per toglierle di mezzo.

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에서 올바르게 동작할 수 없다.

Interfaccia binaria del kernel
------------------------------

Supponiamo d'avere un'interfaccia stabile nei sorgenti del kernel, di
conseguenza un'interfaccia binaria dovrebbe essere anche'essa stabile, giusto?
Sbagliato.  Prendete in considerazione i seguenti fatti che riguardano il
kernel Linux:

  - A seconda della versione del compilatore C che state utilizzando, diverse
    strutture dati del kernel avranno un allineamento diverso, e possibilmente
    un modo diverso di includere le funzioni (renderle inline oppure no).
    L'organizzazione delle singole funzioni non è poi così importante, ma la
    spaziatura (*padding*) nelle strutture dati, invece, lo è.

  - In base alle opzioni che sono state selezionate per generare il kernel,
    un certo numero di cose potrebbero succedere:

      - strutture dati differenti potrebbero contenere campi differenti
      - alcune funzioni potrebbero non essere implementate (per esempio,
        alcuni *lock* spariscono se compilati su sistemi mono-processore)
      - la memoria interna del kernel può essere allineata in differenti modi
        a seconda delle opzioni di compilazione.

  - Linux funziona su una vasta gamma di architetture di processore. Non esiste
    alcuna possibilità che il binario di un driver per un'architettura funzioni
    correttamente su un'altra.

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 방식을 장기간 지원하는 것은 현실적으로 감당하기 어렵다.

Alcuni di questi problemi possono essere risolti compilando il proprio modulo
con la stessa identica configurazione del kernel, ed usando la stessa versione
del compilatore usato per compilare il kernel.  Questo è sufficiente se volete
fornire un modulo per uno specifico rilascio su una specifica distribuzione
Linux.  Ma moltiplicate questa singola compilazione per il numero di
distribuzioni Linux e il numero dei rilasci supportati da quest'ultime e vi
troverete rapidamente in un incubo fatto di configurazioni e piattaforme
hardware (differenti processori con differenti opzioni); dunque, anche per il
singolo rilascio di un modulo, dovreste creare differenti versioni dello
stesso.

Fidatevi, se tenterete questa via, col tempo, diventerete pazzi; l'ho imparato
a mie spese molto tempo fa...

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는 계속 올바르게 동작한다.

Interfaccia stabile nei sorgenti del kernel
-------------------------------------------

Se parlate con le persone che cercano di mantenere aggiornato un driver per
Linux ma che non si trova nei sorgenti, allora per queste persone l'argomento
sarà "ostico".

Lo sviluppo del kernel Linux è continuo e viaggia ad un ritmo sostenuto, e non
rallenta mai.  Perciò, gli sviluppatori del kernel trovano bachi nelle
interfacce attuali, o trovano modi migliori per fare le cose.  Se le trovano,
allora le correggeranno per migliorarle.  In questo frangente, i nomi delle
funzioni potrebbero cambiare, le strutture dati potrebbero diventare più grandi
o più piccole, e gli argomenti delle funzioni potrebbero essere ripensati.
Se questo dovesse succedere, nello stesso momento, tutte le istanze dove questa
interfaccia viene utilizzata verranno corrette, garantendo che tutto continui
a funzionare senza problemi.

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에게 아무 이익 없이 추가 작업을 요구하는 결과가 된다.

Portiamo ad esempio l'interfaccia interna per il sottosistema USB che ha subito
tre ristrutturazioni nel corso della sua vita.  Queste ristrutturazioni furono
fatte per risolvere diversi problemi:

  - È stato fatto un cambiamento da un flusso di dati sincrono ad uno
    asincrono.  Questo ha ridotto la complessità di molti driver e ha
    aumentato la capacità di trasmissione di tutti i driver fino a raggiungere
    quasi la velocità massima possibile.
  - È stato fatto un cambiamento nell'allocazione dei pacchetti da parte del
    sottosistema USB per conto dei driver, cosicché ora i driver devono fornire
    più informazioni al sottosistema USB al fine di correggere un certo numero
    di stalli.

Questo è completamente l'opposto di quello che succede in alcuni sistemi
operativi proprietari che hanno dovuto mantenere, nel tempo, il supporto alle
vecchie interfacce USB.  I nuovi sviluppatori potrebbero usare accidentalmente
le vecchie interfacce e sviluppare codice nel modo sbagliato, portando, di
conseguenza, all'instabilità del sistema.

In entrambe gli scenari, gli sviluppatori hanno ritenuto che queste importanti
modifiche erano necessarie, e quindi le hanno fatte con qualche sofferenza.
Se Linux avesse assicurato di mantenere stabile l'interfaccia interna, si
sarebbe dovuto procedere alla creazione di una nuova, e quelle vecchie, e
mal funzionanti, avrebbero dovuto ricevere manutenzione, creando lavoro
aggiuntivo per gli sviluppatori del sottosistema USB.  Dato che gli
sviluppatori devono dedicare il proprio tempo a questo genere di lavoro,
chiedergli di dedicarne dell'altro, senza benefici, magari gratuitamente, non
è contemplabile.

Security 수정과 unused interface 정리

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

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

Le problematiche relative alla sicurezza sono molto importanti per Linux.
Quando viene trovato un problema di sicurezza viene corretto in breve tempo.
A volte, per prevenire il problema di sicurezza, si sono dovute cambiare
delle interfacce interne al kernel.  Quando è successo, allo stesso tempo,
tutti i driver che usavano quelle interfacce sono stati aggiornati, garantendo
la correzione definitiva del problema senza doversi preoccupare di rivederlo
per sbaglio in futuro.  Se non si fossero cambiate le interfacce interne,
sarebbe stato impossibile correggere il problema e garantire che non si sarebbe
più ripetuto.

Nel tempo le interfacce del kernel subiscono qualche ripulita.  Se nessuno
sta più usando un'interfaccia, allora questa verrà rimossa.  Questo permette
al kernel di rimanere il più piccolo possibile, e garantisce che tutte le
potenziali interfacce sono state verificate nel limite del possibile (le
interfacce inutilizzate sono impossibili da verificare).

해결책은 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되고 동작한다.

Cosa fare
---------

Dunque, se avete un driver per il kernel Linux che non si trova nei sorgenti
principali del kernel, come sviluppatori, cosa dovreste fare?  Rilasciare un
file binario del driver per ogni versione del kernel e per ogni distribuzione,
è un incubo; inoltre, tenere il passo con tutti i cambiamenti del kernel è un
brutto lavoro.

Semplicemente, fate sì che il vostro driver per il kernel venga incluso nei
sorgenti principali (ricordatevi, stiamo parlando di driver rilasciati secondo
una licenza compatibile con la GPL; se il vostro codice non ricade in questa
categoria: buona fortuna, arrangiatevi, siete delle sanguisughe)

Se il vostro driver è nei sorgenti del kernel e un'interfaccia cambia, il
driver verrà corretto immediatamente dalla persona che l'ha modificata.  Questo
garantisce che sia sempre possibile compilare il driver, che funzioni, e tutto
con un minimo sforzo da parte vostra.

Main tree driver가 얻는 이점

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

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

Avere il proprio driver nei sorgenti principali del kernel ha i seguenti
vantaggi:

  - La qualità del driver aumenterà e i costi di manutenzione (per lo
    sviluppatore originale) diminuiranno.
  - Altri sviluppatori aggiungeranno nuove funzionalità al vostro driver.
  - Altri persone troveranno e correggeranno bachi nel vostro driver.
  - Altri persone troveranno degli aggiustamenti da fare al vostro driver.
  - Altri persone aggiorneranno il driver quando è richiesto da un cambiamento
    di un'interfaccia.
  - Il driver sarà automaticamente reso disponibile in tutte le distribuzioni
    Linux senza dover chiedere a nessuna di queste di aggiungerlo.

Dato che Linux supporta più dispositivi di qualsiasi altro sistema operativo,
e che girano su molti più tipi di processori di qualsiasi altro sistema
operativo; ciò dimostra che questo modello di sviluppo qualcosa di giusto,
dopo tutto, lo fa :)

초기 문서 검토 기여

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

------

Dei ringraziamenti vanno a Randy Dunlap, Andrew Morton, David Brownell,
Hanna Linder, Robert Love, e Nishanth Aravamudan per la loro revisione
e per i loro commenti sulle prime bozze di questo articolo.