개발 초기 계획

code보다 먼저 하는 계획

Kernel 개발 project를 생각하면 바로 code를 쓰고 싶지만 성공에 필요한 기반은 첫 줄을 작성하기 전에 만드는 편이 좋다. 초기 planning과 communication에 시간을 쓰면 이후 훨씬 많은 시간을 절약할 수 있다.

kernel project를 시작할 때 바로 구현부터 하고 싶기 쉽지만, 성공 여부를 좌우하는 문제 정의·관련 subsystem 조사·community communication은 첫 code line보다 먼저 이루어져야 합니다. 초기에 쓴 시간은 뒤의 재설계와 review 비용을 크게 줄입니다.

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

:Original: :ref:`Documentation/process/3.Early-stage.rst <development_early_stage>`
:Translator: Alessia Mantegazza <[email protected]>

.. _it_development_early_stage:

I primi passi della pianificazione
==================================

Osservando un progetto di sviluppo per il kernel Linux, si potrebbe essere
tentati dal saltare tutto e iniziare a codificare.  Tuttavia, come ogni
progetto significativo, molta della preparazione per giungere al successo
viene fatta prima che una sola linea di codice venga scritta.  Il tempo speso
nella pianificazione e la comunicazione può far risparmiare molto
tempo in futuro.

문제와 특정 해법 구분하기

성공적인 kernel 개선은 해결할 문제를 명확히 설명하는 데서 시작한다. 특정 hardware driver처럼 문제가 분명한 경우도 있지만 제안한 solution을 실제 problem과 혼동하면 어려움이 생긴다.

과거 Linux audio developer는 excessive latency로 생기는 dropout을 막으려고 특정 application에 realtime scheduler 접근을 주는 LSM hook 기반 kernel module을 만들었다. Linux-kernel mailing list에 제출하자 즉시 반대에 부딪혔다.

Audio developer에게 module은 당장 문제를 해결했지만 kernel community는 원래 없던 privilege를 process에 부여하는 방식이 LSM 오용이며 system stability 위험이라고 보았다. Community는 단기적으로 rlimit을 통한 realtime scheduling access, 장기적으로 kernel latency 감소 작업을 선호했다.

Audio 측은 이미 구현한 solution을 넘어 대안을 받아들이지 못했고 kernel 개발 절차에 환멸을 느꼈다. 원문은 한 developer가 kernel developer를 비난한 인용을 https://lwn.net/Articles/131776/ 에서 소개한다.

실제로 kernel developer는 특정 module보다 system stability, 장기 maintenance, 문제에 맞는 올바른 solution에 관심이 있었다. 교훈은 code에 투자하기 전에 특정 해법이 아니라 문제 자체에 집중하고 community와 논의하라는 것이다.

• 정확히 어떤 문제를 해결해야 하는가?
• 누가 이 문제의 영향을 받고 solution은 어떤 use case를 다뤄야 하는가?
• 현재 kernel은 이 문제를 해결하는 데 어떤 점이 부족한가?

이 질문에 답한 뒤에야 가능한 solution을 검토할 의미가 있다.

특정 구현을 이미 정한 뒤 이를 문제 자체처럼 제시하면 community가 제안하는 더 안전하고 일반적인 대안을 받아들이기 어렵습니다. audio latency 사례에서는 LSM module보다 `rlimit` 기반 권한과 kernel latency 개선이 장기 해법으로 선택됐습니다.

구현 전에는 정확한 문제, 영향을 받는 사용자와 use case, 현재 kernel이 부족한 지점을 먼저 적어야 합니다. 이 세 질문에 답한 뒤에야 어떤 interface와 subsystem 변경이 적절한지 비교할 수 있습니다.

Specificare il problema
-----------------------

Come qualsiasi progetto ingegneristico, un miglioramento del kernel di
successo parte con una chiara descrizione del problema da risolvere.
In alcuni casi, questo passaggio è facile: ad esempio quando un driver è
richiesto per un particolare dispositivo.  In altri casi invece, si
tende a confondere il problema reale con le soluzioni proposte e questo
può portare all'emergere di problemi.

Facciamo un esempio: qualche anno fa, gli sviluppatori che lavoravano con
linux audio cercarono un modo per far girare le applicazioni senza dropouts
o altri artefatti dovuti all'eccessivo ritardo nel sistema.  La soluzione
alla quale giunsero fu un modulo del kernel destinato ad agganciarsi al
framework Linux Security Module (LSM); questo modulo poteva essere
configurato per dare ad una specifica applicazione accesso allo
schedulatore *realtime*.  Tale modulo fu implementato e inviato nella
lista di discussione linux-kernel, dove incontrò subito dei problemi.

Per gli sviluppatori audio, questo modulo di sicurezza era sufficiente a
risolvere il loro problema nell'immediato.  Per l'intera comunità kernel,
invece, era un uso improprio del framework LSM (che non è progettato per
conferire privilegi a processi che altrimenti non avrebbero potuto ottenerli)
e un rischio per la stabilità del sistema.  Le loro soluzioni di punta nel
breve periodo, comportavano un accesso alla schedulazione realtime attraverso
il meccanismo rlimit, e nel lungo periodo un costante lavoro nella riduzione
dei ritardi.

La comunità audio, comunque, non poteva vedere al di là della singola
soluzione che avevano implementato; erano riluttanti ad accettare alternative.
Il conseguente dissenso lasciò in quegli sviluppatori un senso di
disillusione nei confronti dell'intero processo di sviluppo; uno di loro
scrisse questo messaggio:

	Ci sono numerosi sviluppatori del kernel Linux davvero bravi, ma
	rischiano di restare sovrastati da una vasta massa di stolti arroganti.
	Cercare di comunicare le richieste degli utenti a queste persone è
	una perdita di tempo. Loro sono troppo "intelligenti" per stare ad
	ascoltare dei poveri mortali.

	(http://lwn.net/Articles/131776/).

La realtà delle cose fu differente; gli sviluppatori del kernel erano molto
più preoccupati per la stabilità del sistema, per la manutenzione di lungo
periodo e cercavano la giusta soluzione alla problematica esistente con uno
specifico modulo.  La morale della storia è quella di concentrarsi sul
problema - non su di una specifica soluzione- e di discuterne con la comunità
di sviluppo prima di investire tempo nella scrittura del codice.

Quindi, osservando un progetto di sviluppo del kernel, si dovrebbe
rispondere a questa lista di domande:

- Qual'è, precisamente, il problema che dev'essere risolto?

- Chi sono gli utenti coinvolti da tal problema? A quale caso dovrebbe
  essere indirizzata la soluzione?

- In che modo il kernel risulta manchevole nell'indirizzare il problema
  in questione?

Solo dopo ha senso iniziare a considerare le possibili soluzioni.

조기 논의와 닫힌 개발의 비용

• Kernel이 이미 예상하지 못한 방식으로 문제를 해결하고 있을 수 있다. Linux는 크고 문서화가 완전하지 않아 기존 기능을 놓치기 쉽다. 기존 driver와 같은 기능을 다시 구현한 새 driver는 낭비이며 mainline에 accept되지 않는다.
• 제안한 solution 일부가 mainline merge 기준에 맞지 않을 수 있다. Code를 쓰기 전에 아는 것이 낫다.
• 다른 developer가 같은 문제를 고민해 더 나은 idea를 갖고 있거나 구현을 도울 수 있다.

Community와 격리된 채 설계하고 개발한 kernel code는 공개 뒤에야 문제가 드러나는 경우가 많다. 심하면 community 기준에 맞추는 데 수개월 또는 수년이 걸린다.

• Devicescape network stack은 UP system만 가정해 설계되었다. SMP locking을 뒤늦게 추가하는 어려움 때문에 mac80211로 mainline에 merge되기까지 1년 넘게 지연되었다.
• Reiser4는 core developer가 VFS layer에 있어야 한다고 본 기능과 user가 유발할 수 있는 deadlock 위험을 포함했다. 문제가 늦게 드러났고 일부 수정이 거부되어 mainline 밖에 남았다.
• AppArmor는 internal VFS data structure를 안전하지 않고 신뢰하기 어려운 방식으로 사용했다. 이 문제를 포함한 여러 우려로 mainline 포함이 수년 지연되었다.

세 사례 모두 kernel developer와 일찍 논의했다면 큰 고통과 추가 작업을 줄일 수 있었다.

구현 전에 논의하면 kernel이 이미 제공하는 기능, mainline 기준에 맞지 않는 설계, 같은 문제를 연구하는 다른 개발자를 일찍 발견할 수 있습니다. 공개 없이 개발한 code는 integration 단계에서 SMP, VFS, locking 같은 근본 가정을 다시 고쳐야 할 수 있습니다.

Devicescape stack, Reiser4, AppArmor 사례는 기능이 동작하는 것만으로 upstream 준비가 끝나지 않음을 보여 줍니다. subsystem 전체의 규약과 deadlock·data structure lifetime을 초기에 함께 검토해야 수개월 또는 수년의 지연을 피할 수 있습니다.

Prime discussioni
-----------------

Quando si pianifica un progetto di sviluppo per il kernel, sarebbe quanto meno
opportuno discuterne inizialmente con la comunità prima di lanciarsi
nell'implementazione.  Una discussione preliminare può far risparmiare sia
tempo che problemi in svariati modi:

 - Potrebbe essere che il problema sia già stato risolto nel kernel in
   una maniera che non avete ancora compreso.  Il kernel Linux è grande e ha
   una serie di funzionalità e capacità che non sono scontate nell'immediato.
   Non tutte le capacità del kernel sono documentate così bene come ci
   piacerebbe, ed è facile perdersi qualcosa.  Il vostro autore ha assistito
   alla pubblicazione di un driver intero che duplica un altro driver
   esistente di cui il nuovo autore era ignaro.  Il codice che rinnova
   ingranaggi già esistenti non è soltanto dispendioso; non verrà nemmeno
   accettato nel ramo principale del kernel.

 - Potrebbero esserci proposte che non sono considerate accettabili per
   l'integrazione all'interno del ramo principale. È meglio affrontarle
   prima di scrivere il codice.

 - È possibile che altri sviluppatori abbiano pensato al problema; potrebbero
   avere delle idee per soluzioni migliori, e potrebbero voler contribuire
   alla loro creazione.

Anni di esperienza con la comunità di sviluppo del kernel hanno impartito una
chiara lezione: il codice per il kernel che è pensato e sviluppato a porte
chiuse, inevitabilmente, ha problematiche che si rivelano solo quando il
codice viene rilasciato pubblicamente.  Qualche volta tali problemi sono
importanti e richiedono mesi o anni di sforzi prima che il codice possa
raggiungere gli standard richiesti della comunità.
Alcuni esempi possono essere:

 - La rete Devicescape è stata creata e implementata per sistemi
   mono-processore.  Non avrebbe potuto essere inserita nel ramo principale
   fino a che non avesse supportato anche i sistemi multi-processore.
   Riadattare i meccanismi di sincronizzazione e simili è un compito difficile;
   come risultato, l'inserimento di questo codice (ora chiamato mac80211)
   fu rimandato per più di un anno.

 - Il filesystem Reiser4 include una seria di funzionalità che, secondo
   l'opinione degli sviluppatori principali del kernel, avrebbero dovuto
   essere implementate a livello di filesystem virtuale.  Comprende
   anche funzionalità che non sono facilmente implementabili senza esporre
   il sistema al rischio di uno stallo.  La scoperta tardiva di questi
   problemi - e il diniego a risolverne alcuni - ha avuto come conseguenza
   il fatto che Raiser4 resta fuori dal ramo principale del kernel.

 - Il modulo di sicurezza AppArmor utilizzava strutture dati del
   filesystem virtuale interno in modi che sono stati considerati rischiosi e
   inattendibili.  Questi problemi (tra le altre cose) hanno tenuto AppArmor
   fuori dal ramo principale per anni.

Ciascuno di questi casi è stato un travaglio e ha richiesto del lavoro
straordinario, cose che avrebbero potuto essere evitate con alcune
"chiacchierate" preliminari con gli sviluppatori kernel.

관련 list와 maintainer 찾기

계획을 공개할 때는 관련 mailing list와 maintainer를 찾는다. MAINTAINERS file에서 적합한 subsystem list를 찾고, 가능하면 일반 linux-kernel보다 해당 list에 게시해 전문성을 가진 developer에게 도달한다.

MAINTAINERS가 오래되었거나 subsystem이 누락되고 명시된 사람이 실제 역할을 하지 않을 수 있다. 의심스러우면 git log로 최근 patch author와 Signed-off-by를 붙이는 사람을 찾아 현재 활동 중인 maintainer를 확인한다.

scripts/get_maintainer.pl

-f option은 file 또는 directory maintainer를 찾고 patch file을 넘기면 Cc해야 할 사람을 나열한다. Patch 자체를 입력하는 방식이 -f보다 권장된다. Aggressive search option은 실제 관심이 없는 developer까지 포함할 수 있으므로 주의한다. 다른 방법이 모두 실패하면 문서 작성 당시에는 Andrew Morton에게 문의해 maintainer를 찾을 수 있었다.

계획은 `MAINTAINERS`에서 찾은 관련 subsystem mailing list와 maintainer에게 공개합니다. 항목이 오래됐거나 누락됐다면 `git log`의 최근 author와 Signed-off-by 흐름으로 실제 활동 중인 담당자를 확인합니다.

`scripts/get_maintainer.pl`에 patch를 넘기면 code와 history를 바탕으로 수신자 목록을 구할 수 있습니다. `-f`로 file만 지정하는 것보다 실제 patch를 입력하는 방법이 권장되며, 지나치게 공격적인 탐색 옵션은 관련 없는 개발자를 Cc할 수 있습니다.

Con chi parlare?
----------------

Quando gli sviluppatori hanno deciso di rendere pubblici i propri progetti, la
domanda successiva sarà: da dove partiamo?  La risposta è quella di trovare
la giusta lista di discussione e il giusto manutentore.  Per le liste di
discussione, il miglior approccio è quello di cercare la lista più adatta
nel file MAINTAINERS.  Se esiste una lista di discussione di sottosistema,
è preferibile pubblicare lì piuttosto che sulla lista di discussione generale
del kernel Linux; avrete maggiori probabilità di trovare sviluppatori con
esperienza sul tema, e l'ambiente che troverete potrebbe essere più
incoraggiante.

Trovare manutentori può rivelarsi un po' difficoltoso.  Ancora, il file
MAINTAINERS è il posto giusto da dove iniziare.  Il file potrebbe non essere
sempre aggiornato, inoltre, non tutti i sottosistemi sono rappresentati qui.
Coloro che sono elencati nel file MAINTAINERS potrebbero, in effetti, non
essere le persone che attualmente svolgono quel determinato ruolo.  Quindi,
quando c'è un dubbio su chi contattare, un trucco utile è quello di usare
git (git log in particolare) per vedere chi attualmente è attivo all'interno
del sottosistema interessato.  Controllate chi sta scrivendo le patch,
e chi, se non ci fosse nessuno, sta aggiungendo la propria firma
(Signed-off-by) a quelle patch.  Quelle sono le persone maggiormente
qualificate per aiutarvi con lo sviluppo di nuovo progetto.

Il compito di trovare il giusto manutentore, a volte, è una tale sfida che
ha spinto gli sviluppatori del kernel a scrivere uno script che li aiutasse
in questa ricerca:

::

	.../scripts/get_maintainer.pl

Se questo script viene eseguito con l'opzione "-f" ritornerà il manutentore(i)
attuale per un dato file o cartella. Se viene passata una patch sulla linea di
comando, lo script elencherà i manutentori che dovrebbero riceverne una copia.
Questo è la maniera raccomandata (non quella con "-f") per ottenere la lista di
persone da aggiungere a Cc per le vostre patch. Ci sono svariate opzioni che
regolano quanto a fondo get_maintainer.pl debba cercare i manutentori; siate
quindi prudenti nell'utilizzare le opzioni più aggressive poiché potreste finire
per includere sviluppatori che non hanno un vero interesse per il codice che
state modificando.

Se tutto ciò dovesse fallire, parlare con Andrew Morton potrebbe essere
un modo efficace per capire chi è il manutentore di un dato pezzo di codice.

계획 게시 시점과 무응답

가능하면 초기 단계에 해결할 문제와 구현 계획을 게시한다. 정보가 많을수록 community가 유용한 의견을 주기 쉽다.

적대적 반응보다 아무 반응도 없는 상황이 생길 수 있다. Kernel developer는 바쁘고 실현 code가 없는 큰 계획도 많으며 누구도 타인의 idea를 review할 의무가 없다. High-level design은 구현할 때만 보이는 문제를 숨기므로 developer가 실제 code를 선호하기도 한다.

RFC에 comment가 없다고 관심이 없거나 문제가 없다고 단정할 수 없다. 이때는 작업을 진행하되 과정에서 community에 계속 알린다.

해결할 문제와 구현 계획은 가능한 한 일찍 게시하되, 구체적인 use case와 예상 interface를 함께 제공해야 유용한 feedback을 받을 가능성이 높아집니다. 실제 code가 없는 큰 계획은 우선순위가 낮아 답이 늦을 수 있습니다.

RFC에 답이 없다고 동의나 거절로 해석해서는 안 됩니다. 제한된 prototype을 진행하면서 새 정보를 계속 공유하고, 구현 과정에서 드러난 제약을 반영해 논의를 구체화합니다.

Quando pubblicare
-----------------

Se potete, pubblicate i vostri intenti durante le fasi preliminari, sarà
molto utile.  Descrivete il problema da risolvere e ogni piano che è stato
elaborato per l'implementazione.  Ogni informazione fornita può aiutare
la comunità di sviluppo a fornire spunti utili per il progetto.

Un evento che potrebbe risultare scoraggiate e che potrebbe accadere in
questa fase non è il ricevere una risposta ostile, ma, invece, ottenere
una misera o inesistente reazione.  La triste verità è che: (1) gli
sviluppatori del kernel tendono ad essere occupati, (2) ci sono tante persone
con grandi progetti e poco codice (o anche solo la prospettiva di
avere un codice) a cui riferirsi e (3) nessuno è obbligato a revisionare
o a fare osservazioni in merito ad idee pubblicate da altri.  Oltre a
questo, progetti di alto livello spesso nascondono problematiche che si
rivelano solo quando qualcuno cerca di implementarle; per questa ragione
gli sviluppatori kernel preferirebbero vedere il codice.

Quindi, se una richiesta pubblica di commenti riscuote poco successo, non
pensate che ciò significhi che non ci sia interesse nel progetto.
Sfortunatamente, non potete nemmeno assumere che non ci siano problemi con
la vostra idea.  La cosa migliore da fare in questa situazione è quella di
andare avanti e tenere la comunità informata mentre procedete.

회사 승인과 비공개 사전 검토

회사 환경에서 개발한다면 계획이나 code를 public list에 게시할 권한을 적절한 manager에게 받아야 한다. GPL-compatible license로 release 승인을 받지 않은 code를 게시하면 특히 문제가 되므로 management와 legal team이 이른 시점에 합의해야 한다.

아직 공개되지 않은 제품을 지원하는 작업은 employer 계획을 public list에 밝히기 어려울 수 있다. 먼저 secrecy가 정말 필요한지 검토한다.

실제로 조기 공개가 불가능하고 사내 경험 많은 kernel developer도 없다면 외부 developer와 NDA를 맺고 계획을 검토받는 방법이 있다. Linux Foundation은 https://www.linuxfoundation.org/nda/ 의 NDA program을 제공한다. 이런 비공개 review만으로도 project를 공개하지 않으면서 큰 통합 문제를 예방할 수 있다.

회사에서 개발한다면 public list에 계획과 code를 올릴 권한, GPL-compatible license 제공과 sign-off 가능 여부를 management와 legal team에 초기에 확인해야 합니다. 공개 후 승인 문제를 발견하면 project와 community 모두에 큰 비용이 생깁니다.

미공개 제품 때문에 조기 공개가 정말 불가능하다면 경험 많은 외부 kernel developer와 NDA를 맺고 비공개 설계 review를 받을 수 있습니다. 공개 review를 완전히 대체하지는 못하지만 구조적 integration 문제를 제품 공개 전에 찾는 데 도움이 됩니다.

Ottenere riscontri ufficiali
----------------------------

Se il vostro lavoro è stato svolto in un ambiente aziendale - come molto
del lavoro fatto su Linux - dovete, ovviamente, avere il permesso dei
dirigenti prima che possiate pubblicare i progetti, o il codice aziendale,
su una lista di discussione pubblica.  La pubblicazione di codice che non
è stato rilascio espressamente con licenza GPL-compatibile può rivelarsi
problematico; prima la dirigenza, e il personale legale, troverà una decisione
sulla pubblicazione di un progetto, meglio sarà per tutte le persone coinvolte.

A questo punto, alcuni lettori potrebbero pensare che il loro lavoro sul
kernel è preposto a supportare un prodotto che non è ancora ufficialmente
riconosciuto.  Rivelare le intenzioni dei propri datori di lavori in una
lista di discussione pubblica potrebbe non essere una soluzione valida.
In questi casi, vale la pena considerare se la segretezza sia necessaria
o meno; spesso non c'è una reale necessità di mantenere chiusi i progetti di
sviluppo.

Detto ciò, ci sono anche casi dove l'azienda legittimamente non può rivelare
le proprie intenzioni in anticipo durante il processo di sviluppo.  Le aziende
che hanno sviluppatori kernel esperti possono scegliere di procedere a
carte coperte partendo dall'assunto che saranno in grado di evitare, o gestire,
in futuro, eventuali problemi d'integrazione. Per le aziende senza questo tipo
di esperti, la migliore opzione è spesso quella di assumere uno sviluppatore
esterno che revisioni i progetti con un accordo di segretezza.
La Linux Foundation applica un programma di NDA creato appositamente per
aiutare le aziende in questa particolare situazione; potrete trovare più
informazioni sul sito:

    http://www.linuxfoundation.org/en/NDA_program

Questa tipologia di revisione è spesso sufficiente per evitare gravi problemi
senza che sia richiesta l'esposizione pubblica del progetto.