[Linux-Biella] Introduction to linux kernel development process

[Andrea Ferraris]

Paolo Ciarrocchi ha scritto:

> Ciao a tutti,
> sto scrivendo un articolo illustrando come funziona il processo di sviluppo
> del kernel di linux, è in inglese ma spero possa essere inserito nella sezione
> di manualistica del bilug (alcune persone mi hanno chiesto di postare
> il link su lkml
> appena l'articolo è pronto).
> 
> Commenti, suggerimenti e correzzioni al mio inglese sono molto apprezzate :-)

Grazie Paolo per il bel lavoro (per le eventuali correzioni non sono in 
grado/tempo).

Sono completamente responsabile degli errori di traduzione, mentre il
merito di quelli di contenuto e` completamente tuo :-)

                Introduction to linux kernel development process
	Introduzione al processo di sviluppo del kernel di Linux

           (Written by Paolo Ciarrocchi, November 2005)
           (di Paolo Ciarrocchi, Novembre 2005)

                      (http://technologynews.altervista.org)
                      (ptit://notizietecnologiche.altravista.org)


> 		---- Overview ----

                 ++++ Panoramica ++++

> Linux kernel development process is quite complex and not very well documented
> so I decided to try to summarize it in the hope to be usefull for the community.

Il processo di sviluppo del kernel di Linux e` abbastanza complesso e
non molto ben documentato, cosi` ho deciso di provare a riassumerlo
nella speranza di essere utile alla comunita`.

> 2.6.x kernels are the base stable releases released by Linus.

I kernel 2.6.x sono le release stabili di base rilasciate da Linus.

> The highest numbered release is the most recent.

La release col numero piu` alto e` la piu` recente.

> If regressions or other serious flaws are found then a -stable fix patch
> will be released (see below) on top of this base. Once a new 2.6.x base
> kernel is released, a patch is made available that is a delta between the
> previous 2.6.x kernel and the new one.

Se vengono trovate delle regressioni o altri seri difetti, allora viene
rilasciata una correzione -stabile (vedi oltre) su questa base. Dopo il
rilascio di un nuovo kernel base 2.6.x, e` resa disponibile una patch
che e` la differenza fra il kernel 2.6.x precedente e il nuovo.


>                   --- 2.6.x kernels ---

                     +++ kernel 2.6.x +++

> 2.6.x kernels are maintained by Linus Torvalds,

I kernel 2.6.x sono manutenuti da Linus Torvalds,

> it's development is as follow:

Il loro sviluppo avviene cosi`:

>
>- As soon a new kernel is released a two weeks windows is open, during
>  this period of time maintainers can submit big diffs to Linus,
>  usually the patched sited in -mm kernels for a few weeks.

Non appena e` rilasciato un nuovo kernel, si apre una finestra di 2
settimane, durante la quale i manutentori possono sottomettere grosse
modifiche a Linus, normalmente queste patche sono state prima nei kernel
-mm per qualche settimana.

>  Preferred way to submit big changes is using GIT
>  (more information about GIT at http://git.or.cz/ and
>  http://www.kernel.org/pub/software/scm/git/docs/tutorial.html).

Il modo preferenziale per sottoporre grosse modifiche e` di usare GIT
(> informazioni riguardo a GIT a ptit://git.or.cz e
ptit://www.kernel.org//pub/software/scm/git/docs/tutorial.html).

>- After two weeks a -rc1 kernel is released and now is possible to
>  push only patches that do not include new functionalities that could
>  affect the stability of the whole kernel. Please note that a whole
>  new driver (or filesystem) might be accepted
>  after -rc1 because there is no risk of causing regressions with
>  such a change

Dopo due settimane e` rilasciato un kernel -rc1 e ora e` possibile
introdurre solo patch che non includono nuove funzionalita` che possano
interessare la stabilita` dell'intero kernel. Notate che un driver
interamente nuovo (o file system) potrebbe essere accettato dopo -rc1
perche' non c'e` rischio di causare regressioni con un cambiamento di
questo tipo.

>- A new -rc is released whenever Linus deems the current git
> (the kernel's source management) tree to be in a reasonably sane state
>  adequate for testing. The goal is to release a new -rc kernel every
> week.

Ogni volta che Linus considera che l'attuale git (la gestione dei
sorgenti del kernel) sia in uno stato ragionevolmente stabile, adeguato
per essere sperimentato, viene rilasciato un nuovo -rc.

>- Process continues until the kernel is considered "ready", the
>  process should last around 6 weeks ( 6 kernels per year should be
>  released) an usually includes 4/5 rc releases.

Il processo continua fino a quando il kernel e` considerato "pronto" e
dovrebbe durare circa 6 settimane (dovrebbero essere rilasciati 6 kernel
all'anno) e normalmente comprende 4/5 release rc.

> There a numbers of tools used by the community to measure the quality 
> and the performance of a kernel.

Ci sono una quantita` di strumenti impiegati dalla comunita` per
misurare la qualita` e le prestazioni del kernel.

> A couple of examples are:

Un paio di esempi sono:

>- kernel-perf.sourceforge.net
>	Copy and paste from the project description:

Copia e incolla dalla descrizione del progetto:

>	 "We are a group of dedicated Linux kernel engineers taking on >the 
challenge
>	  of testing the Linux kernel. In order to track performance, we >are 
running
>	  a large set of benchmarks covering core components of the >Linux 
kernel
>	  (virtual memory management, I/O subsystem, process scheduler, >file 
system,
>	  network, device driver, etc). Benchmarks are run on a variety >of 
platforms
>	  every week, testing the latest snapshot of Linus' git >development 
tree.
>	  Comprehensive performance data from our tests will be hosted >here for
>	  easy access."

	 "We are a group of dedicated Linux kernel engineers taking on the
challenge
	  of testing the Linux kernel. In order to track performance, we are
running
	  a large set of benchmarks covering core components of the Linux kernel
	  (virtual memory management, I/O subsystem, process scheduler, file
system,
	  network, device driver, etc). Benchmarks are run on a variety of
platforms
	  every week, testing the latest snapshot of Linus' git development tree.
	  Comprehensive performance data from our tests will be hosted here for
	  easy access."

>- bugzilla.kernel.org
>  It's the official bugzilla instance used as an online kernel bug 
>tracking.

E' l'istanza ufficiale di bugzilla impiegata per tracciare i
bachi del kernel.

>  Users are invited to report all the bugs they hit using this tool.

Gli utenti sono invitati a riportare tutti i bachi che trovano 
impiegando questo strumento.

> But it's worth to mention what Andrew Morton wrote on lkml:
> "Nobody knows when a kernel will be released, because it's released
>  according to perceived bug status, not according to a preconceived
>  timeline."

Ma vale la pena di citare quanto ha scritto Andrea Mortone su lkml:
"Nessuno sa quando sara` rilasciato un kernel, perche' e` rilasciato in
accordo allo stato percepito dei bachi e non a una scadenza prestabilita."

>                     --- 2.6.x.y kernels, a.k.a -stable ---

                       +++ kernel 2.6.x.y , a.c.c -stable +++

>Kernels with 4 digit versions are -stable kernels. They contain 
>small(ish)
>critical fixes for security problems or significant regressions 
>discovered
>in a given 2.6.x kernel.

Le versioni di kernel con 4 cifre sono kernel -stable. Essi contengono
correzioni critiche piccole (o abbastanza piccole) per problemi di
sicurezza o regressioni significative che sono state scoperte in un dato
kernel 2.6.x.

>This is the recommended branch for users who want the most recent >stable
>kernel and are not interested in helping test development/experimental
>versions.

Questo e` il ramo per gli utenti che vogliono il kernel stabile piu`
recente e non sono interessati ad aiutare nel test delle versioni di
sviluppo/sperimentali.

>If no 2.6.x.y kernel is available, then the highest numbered 2.6.x 
>kernel is the current stable kernel.

Se non e` disponibile un kernel 2.6.x.y, allora il kernel stabile
attuale e` quello con la numerazione 2.6.x piu` alta.

>2.6.x.y are maintained by the "stable" team (stable at kernel dot
>org), are released almost every week.

I 2.6.x.y sono manutenuti dal gruppo "stable" (stable at kernel dot
org) e sono rilasciati quasi ogni settimana.

>Rules on what kind of patches are accepted, and what ones are not, into
>the "-stable" tree:

Regole su quali tipi di patch sono accettate e quali no nell'albero -stable:

> - It must be obviously correct and tested.

deve essere ovviamente corretto e testato.

> - It can not bigger than 100 lines, with context.

Non puo` essere piu` lunga di 100 linee, col contesto

> - It must fix only one thing.

Deve correggere solo una cosa.

> - It must fix a real bug that bothers people (not a, "This could be a
>  problem..." type thing.)

Deve correggere un baco reale che disturba persone (non una cosa del
tipo "Questo potrebbe essere un problema")

> - It must fix a problem that causes a build error (but not for things
>  marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
>  security issue, or some "oh, that's not good" issue.  In short,
>  something critical.

Deve correggere un problema che causa un errore di build (ma non per
cose marcate CONFIG_BROKEN), un oops, un blocco, una corruzione di dati,
un reale problema di sicurezza, o qualcosa del tipo "oh, questo non e`
bello". In breve qualcosa di critico.

> - No "theoretical race condition" issues, unless an explanation of how
>  the race can be exploited.

Non una uscita di "condizione raziale teorica", a meno di una
spiegazione su come la razza possa essere sfruttata. [e` volutamente
sbagliata, ma non riesco a tradurre race in questo contesto, dovrebbe 
essere un errore, ma probabilmente di qualche tipo particolare; una cosa 
grosso modo sensata potrebbe essere: Nessuna "condizione teorica di 
errore", se non c'e` una spiegazione di _come_ l'errore puo` essere 
sfrutatto].

> - It can not contain any "trivial" fixes in it (spelling changes,
>  whitespace cleanups, etc.)

Non puo` contenere nessuna correzione banale (cambiamenti ortografici,
pulizia di spazi, etc...)

> - It must be accepted by the relevant subsystem maintainer.

Deve essere accettata dal manutentore principale del sottosistema.

> - It must follow Documentation/SubmittingPatches rules.

Deve seguire le regole di Documentazione/SubmittingPatches

>Procedure for submitting patches to the -stable tree:

Procedura per sottoporre patch all'albero stabile:

> - Send the patch, after verifying that it follows the above rules, to
>  stable a kernel.org.

mandate la correzione, dopo aver verificato che segua le sopra citate
regole, a stable a kernel.org.

> - The sender will receive an ack when the patch has been accepted into
>  the queue, or a nak if the patch is rejected.  This response might
>  take a few days, according to the developer's schedules.

Il mittente ricevera` una ricevuta quando la patch sara` stata accettata
nella coda o un "respinta al mittente" se la patch e` rifiutata. Questa
risposta puo` richiedere pochi giorni, secondo gli impegni dello
sviluppatore.

> - If accepted, the patch will be added to the -stable queue, for 
>review  by other developers.

Se accettata, la patch sara` aggiunta alla coda -stable per essere
riveduta dagli altri sviluppatori.

> - Security patches should not be sent to this alias, but instead to 
>the documented security a kernel.org.

Le patch di sicurezza non dovrebbero essere spedite a questo alias, ma
piuttosto a security a kernel.org.

>Review cycle:

Ciclo di revisione:

> - When the -stable maintainers decide for a review cycle, the patches
>  will be sent to the review committee, and the maintainer of the
>  affected area of the patch (unless the submitter is the maintainer of
>  the area) and CC: to the linux-kernel mailing list.

Quando i manutentori dello -stable decidono per un ciclo di revisione,
le patch sono inviate al comitato dei revisori e al manutentore
dell'area interessata dalla patch (a meno che colui che la sottomette
sia il manutentore dell'area) e in CC: alla mailing list linux-kernel.

> - The review committee has 48 hours in which to ack or nak the patch.

Il comitato dei revisori ha 48 ore entro cui accettare o rifiutare la patch.

> - If the patch is rejected by a member of the committee, or >linux-kernel
>  members object to the patch by bringing up issues that the maintainer
>  and members did not realize, the patch will be dropped from the
>  queue.

Se la patch e` respinta da un membro del comitato o i membri di
linux-kernel fanno obiezioni fornendo conclusioni di cui il manutentore
e i membri non si sono resi conto, la patch viene estromessa dalla coda.

> - At the end of the review cycle, the acked patches will be added to
>  the latest -stable release, and a new -stable release will happen.

Alla fine del ciclo di revisione, le patch accettate sono aggiunte
all'ultima release -stable e si avra` un nuovo rilascio.

> - Security patches will be accepted into the -stable tree directly >from
>  the security kernel team, and not go through the normal review cycle.
>  Contact the kernel security team for more details on this procedure.

Le patch di sicurezza sono accettate nell'albero -stable direttamente
dal team di sicurezza del kernel e non passano attraverso il normale
ciclo di revisione. Contattate il team di sicurezza del kernel per
maggiori dettagli su questa procedura.

> Review committee:

Comitato di revisione

> - This will be made up of a number of kernel developers who have
>  volunteered for this task, and a few that haven't.


Esso sara` composto da una numero di sviluppatori del kernel che si
sono offerti volontari per questo compito e pochi che non si sono.


>                            --- The -mm kernels ---
                              +++ I kernel -mm +++


> These are experimental kernels released by Andrew Morton.

Si tratta dei kernel sperimentali rilasciati da Andrea Mortone.

>The -mm tree serves as a sort of proving ground for new features and 
>other experimental patches.

L'albero -mm serve come una sorta di campo di prova per nuove 
caratteristiche e altre patch sperimentali.

>Once a patch has proved its worth in -mm for a while Andrew pushes it
>on to Linus for inclusion in mainline.

Una volta che una patch ha dato prova del suo valore nel -mm per un 
certo tempo, Andrea la invia a Linus per l'inclusione nella linea 
principale.

 > Although it's encouraged that patches flow to Linus via the -mm tree,
 > this is not always enforced.


Sebbene sia incoraggiato il flusso di patch verso Linus tramite l'albero 
-mm, questo non e` sempre esatto [vorrebbe essere il p.p. di esigere, ma 
non so se esista].

 > Subsystem maintainers (or individuals) sometimes push their patches
 > directly to Linus, even though (or after) they have been merged and
 > tested in -mm (or sometimes even without prior testing in -mm).

I manutentori di sottosistema (o singoli individui) talora inviano 
direttamente le loro patch a Linus, anche sebbene (o dopo che) siano 
state incluse e testate nel -mm (o talvolta anche senza test precedenti 
nel -mm)

 >This branch is in constant flux and contains many experimental 
 >features, a
 >lot of debugging patches not appropriate for mainline etc and is the >most
 >experimental of the branches described in this document.

Questa ramo e` in flusso costante e contiene molte caratteristiche 
sperimentali, un mucchio di patch di debug non appropriate per la linea 
principale etc ed e` il piu` sperimentale dei rami descritti in questo 
documento.

 >These kernels are not appropriate for use on systems that are supposed 
 >to be
 >stable and they are more risky to run than any of the other branches 
 >(make
 >sure you have up-to-date backups - that goes for any experimental 
 >kernel but
 >even more so for -mm kernels).

Questi kernel non sono adatti per l'uso su sisemi che sono supposti 
essere stabili ed essi sono piu` rischiosi da far funzionare di 
qualunque degli altri rami (siate sicuri di avere backup aggiornati - 
questo vale per qualsiasi kernel sperimentale, ma a maggior ragione per 
i kernel -mm).

 >These kernels in addition to all the other experimental patches they 
 >contain
 >usually also contain any changes in the mainline -git kernels 
available >at
 >the time of release.

Questi kernel in aggiunta a tutte le altre patch sperimentali, 
normalmente contengono qualsiasi modifica disponibile nella linea 
principale dei kernel -git al momento del rilascio.

 >The -mm kernels are not released on a fixed schedule, but usually a 
few >-mm
 >kernels are released in between each -rc kernel (1 to 3 is common).

I kernel -mm non sono rilasciati con una schedulazione fissa, ma 
normalmente alcuni kernel -mm sono rilasciati tra ogni kernel -rc (e` 
comune da 1 a 3)

 >                            --- The -git kernels ---
                              +++ I kernel -git +++

 >These are daily snapshots of Linus' kernel tree (managed in a git
 >repository, hence the name).

Questi sono snapshot giornalieri dell'albero del kernel di Linus 
(gestiti in un repository git, da qui il nome)

 >These patches are usually released daily and represent the current 
 >state of
 >Linus' tree. They are more experimental than -rc kernels since they are
 >generated automatically without even a cursory glance to see if they >are
 >sane.

Queste patch sono usualmente rilasciate giornalmente e rappresentano lo 
stato attuale dell'albero di Linus. Essi sono piu` sperimentali dei 
kernel -rc perche' sono generati automaticamente senza nemmeno 
un'occhiata sfuggente per vedere che siano sani.

 >I hope you enjoy reading this article and I really deserve
 >special thanks to Tony Luck and Jesper Juhl for their suggestions!!

Spero che vi sia piaciuto leggere questo articolo ed esprimo veramente 
dei ringraziamenti speciali ad Antonio Fortuna e Gespero Juhl per i loro 
suggerimenti!!

[mi e` piaciuto, grazie, n.d.t.]

 >Part of this article is from the document written by Jesper Juhl,
 >you can find it here:
 >http://sosdg.org/~coywolf/lxr/source/Documentation/applying-patches.txt

Parte di questo articolo e` tratto dal documento di Gespero Juhl che 
potete trovare qui:
ptit://sosdg.org/~lupotimido/lxr/sorgente/Documentazione/applicare-patche.txt