Lines Matching +full:in +full:- +full:kernel
1 .. include:: ../disclaimer-ita.rst
11 Lo sviluppo del Kernel agli inizi degli anno '90 era abbastanza libero, con
14 il kernel da allora ha messo in atto un certo numero di procedure per rendere
19 -------------------
21 Gli sviluppatori kernel utilizzano un calendario di rilascio generico, dove
22 ogni due o tre mesi viene effettuata un rilascio importante del kernel.
34 Ciascun rilascio 5.x è un importante rilascio del kernel con nuove
38 linea di confine nello sviluppo del kernel Linux; il kernel utilizza un sistema
43 "finestra di inclusione" viene dichiarata aperta. In quel momento il codice
45 viene incluso nel ramo principale del kernel. La maggior parte delle
52 raccolti e, verificati in anticipo. Il funzionamento di tale procedimento
57 chiusa e rilascerà il primo degli "rc" del kernel.
58 Per il kernel che è destinato ad essere 5.6, per esempio, il rilascio
59 che emerge al termine della finestra d'inclusione si chiamerà 5.6-rc1.
61 passato, e che è iniziato il periodo di stabilizzazione del prossimo kernel.
71 supportati in precedenza; se toccano codice non facente parte di quello
72 attuale, che non causino regressioni e che potrebbero essere aggiunti in
73 sicurezza in un qualsiasi momento)
77 kernel -rc circa una volta alla settimana; e ne usciranno circa 6 o 9 prima
78 che il kernel venga considerato sufficientemente stabile e che il rilascio
87 30 settembre 5.4-rc1, finestra di inclusione chiusa
88 6 ottobre 5.4-rc2
89 13 ottobre 5.4-rc3
90 20 ottobre 5.4-rc4
91 27 ottobre 5.4-rc5
92 3 novembre 5.4-rc6
93 10 novembre 5.4-rc7
94 17 novembre 5.4-rc8
98 In che modo gli sviluppatori decidono quando chiudere il ciclo di sviluppo e
101 procurano problemi su sistemi che hanno funzionato in passato sono considerati
109 in un progetto di questa portata. Arriva un punto dove ritardare il rilascio
110 finale peggiora la situazione; la quantità di modifiche in attesa della
112 regressioni al giro successivo. Quindi molti kernel 5.x escono con una
116 affidato al "squadra stabilità", attualmente composta da Greg Kroah-Hartman.
118 rilascio stabile usando la numerazione 5.x.y. Per essere presa in
121 per il prossimo sviluppo del kernel. Solitamente, passato il loro rilascio
122 iniziale, i kernel ricevono aggiornamenti per più di un ciclo di sviluppo.
123 Quindi, per esempio, la storia del kernel 5.2 appare così (anno 2019):
138 Alcuni kernel sono destinati ad essere kernel a "lungo termine"; questi
143 https://www.kernel.org/category/releases.html
145 Questa selezione di kernel di lungo periodo sono puramente dovuti ai loro
147 quelle versioni. Non ci sono altri kernel a lungo termine in programma per
148 alcun rilascio in arrivo.
151 -----------------------------
154 al ramo principale del kernel. Esiste, invece, una procedura disegnata
162 come una patch viene inserita nel kernel. Ciò che segue è un'introduzione
168 - Progetto. In questa fase sono stabilite quelli che sono i requisiti
169 della modifica - e come verranno soddisfatti. Il lavoro di progettazione
174 - Prima revisione. Le patch vengono pubblicate sulle liste di discussione
175 interessate, e gli sviluppatori in quella lista risponderanno coi loro
177 emergere problemi rilevanti in una patch.
179 - Revisione più ampia. Quando la patch è quasi pronta per essere inserita
181 accettarla - anche se, questa accettazione non è una garanzia che la
183 del sottosistema in questione e nei sorgenti -next (descritti sotto).
188 - Per favore, tenete da conto che la maggior parte dei manutentori ha
195 i necessari aggiornamenti per mantenere la patch aggiornata al kernel
199 - Inclusione nel ramo principale. Eventualmente, una buona patch verrà
201 Linus Torvalds. In questa fase potrebbero emergere nuovi problemi e/o
205 - Rilascio stabile. Ora, il numero di utilizzatori che sono potenzialmente
209 - Manutenzione di lungo periodo. Nonostante sia possibile che uno sviluppatore
212 codice elimina alcuni degli oneri facenti parte della manutenzione, in
218 Uno dei più grandi errori fatti dagli sviluppatori kernel (o dai loro datori
223 Come le modifiche finiscono nel Kernel
224 --------------------------------------
227 del kernel: Linus Torvalds. Ma, per esempio, di tutte le 9500 patch
228 che entrarono nella versione 2.6.38 del kernel, solo 112 (circa
229 l'1,3%) furono scelte direttamente da Linus in persona. Il progetto
230 del kernel è cresciuto fino a raggiungere una dimensione tale per cui
236 Il codice base del kernel è spezzato in una serie si sottosistemi: rete,
239 sviluppatore che ha piena responsabilità di tutto il codice presente in quel
241 (in un certo senso) della parte di kernel che gestiscono; sono coloro che
243 del kernel.
246 del kernel, utilizzando abitualmente (ma certamente non sempre) git.
249 altri metadati. In ogni momento, il manutentore può individuare quale patch
256 principale del kernel. La quantità d'attenzione che Linus presta alle
271 Chiaramente, in un sistema come questo, l'inserimento delle patch all'interno
272 del kernel si basa sul trovare il manutentore giusto. Di norma, inviare
276 Sorgenti -next
277 --------------
279 La catena di sottosistemi guida il flusso di patch all'interno del kernel,
282 Gli sviluppatori si interesseranno alle patch in sospeso per verificare
284 esempio, cambia il prototipo di una funzione fondamentale del kernel andrà in
288 kernel. Uno potrebbe prendere le patch provenienti da tutti i sottosistemi
291 La risposta ci viene sotto forma di sorgenti -next, dove i sottosistemi sono
293 gestito da Andrew Morton, è chiamato "-mm" (memory management, che è l'inizio
294 di tutto). L'-mm integra patch proveniente da una lunga lista di sottosistemi;
297 Oltre a questo, -mm contiene una raccolta significativa di patch che sono
299 state inviate in una lista di discussione, o possono essere applicate ad una
300 parte del kernel per la quale non esiste un sottosistema dedicato.
301 Di conseguenza, -mm opera come una specie di sottosistema "ultima spiaggia";
303 allora è probabile che finirà in -mm. Le patch passate per -mm
305 direttamente a Linus. In un tipico ciclo di sviluppo, circa il 5-10% delle
306 patch andrà nel ramo principale attraverso -mm.
308 La patch -mm correnti sono disponibili nella cartella "mmotm" (-mm of
317 è linux-next, gestito da Stephen Rothwell. I sorgenti linux-next sono, per
319 la prossima finestra di inclusione si chiuderà. I linux-next sono annunciati
320 sulla lista di discussione linux-kernel e linux-next nel momento in cui
323 http://www.kernel.org/pub/linux/kernel/next/
325 Linux-next è divenuto parte integrante del processo di sviluppo del kernel;
327 aver trovato la propria strada in linux-next, a volte anche prima dell'apertura
331 Sorgenti in preparazione
332 ------------------------
334 Nei sorgenti del kernel esiste la cartella drivers/staging/, dove risiedono
335 molte sotto-cartelle per i driver o i filesystem che stanno per essere aggiunti
336 al kernel. Questi restano nella cartella drivers/staging fintanto che avranno
338 all'interno del kernel nel posto più appropriato. Questo è il modo di tener
339 traccia dei driver che non sono ancora in linea con gli standard di codifica
343 Greg Kroah-Hartman attualmente gestisce i sorgenti in preparazione. I driver
345 la propria sotto-cartella in drivers/staging/. Assieme ai file sorgenti
348 accettati nel kernel, e indica anche la lista di persone da inserire in copia
358 riluttanti nell'attivare driver in preparazione. Quindi lo preparazione è,
364 ---------
366 Come è possibile notare dal testo sopra, il processo di sviluppo del kernel
367 dipende pesantemente dalla capacità di guidare la raccolta di patch in
373 In assoluto, nella comunità del kernel, predomina l'uso di git come sistema
376 del software libero. Esso è calibrato per lo sviluppo del kernel, e si
380 del kernel viene richiesta un po' di familiarità con git; anche se non lo
384 Git è ora compreso in quasi tutte le distribuzioni Linux. Esiste una sito che
387 http://git-scm.com/
389 Qui troverete i riferimenti alla documentazione e alle guide passo-passo.
391 Tra gli sviluppatori Kernel che non usano git, la scelta alternativa più
407 rispetto ad un codice in evoluzione. Molti dei più grandi manutentori di
409 integrate. Per la gestione di certe tipologie di sorgenti (-mm, per esempio),
414 --------------------
416 Una grossa parte del lavoro di sviluppo del Kernel Linux viene svolto tramite
421 email, restare incagliati nelle convenzioni in vigore nelle liste Linux,
424 Molte delle liste di discussione del Kernel girano su vger.kernel.org;
427 http://vger.kernel.org/vger-lists.html
429 Esistono liste gestite altrove; un certo numero di queste sono in
432 La lista di discussione principale per lo sviluppo del kernel è, ovviamente,
433 linux-kernel. Questa lista è un luogo ostile dove trovarsi; i volumi possono
437 altro luogo dove la comunità di sviluppo del kernel si unisce per intero;
441 linux-kernel:
443 - Tenete la lista in una cartella separata, piuttosto che inserirla nella
444 casella di posta principale. Così da essere in grado di ignorare il flusso
447 - Non cercate di seguire ogni conversazione - nessuno lo fa. È importante
452 - Non alimentate i troll. Se qualcuno cerca di creare nervosismo, ignoratelo.
454 - Quando rispondete ad una mail linux-kernel (o ad altre liste) mantenete
455 tutti i Cc:. In assenza di importanti motivazioni (come una richiesta
459 in copia nel rispondere al vostro messaggio.
461 - Cercate nell'archivio della lista (e nella rete nella sua totalità) prima
465 - Rispondete sotto alla porzione di righe citate, così da dare un contesto alle
466 vostre risposte, e quindi renderle più leggibili (in altre parole, evitate di
467 rispondere in cima, ovvero prima del testo citato). Per maggiori dettagli
468 leggete :ref:`Documentation/translations/it_IT/process/submitting-patches.rst
472 - Chiedete nella lista di discussione corretta. Linux-kernel può essere un
478 relativa alla rete su linux-kernel riceverà quasi certamente il suggerimento
482 file MAINTAINERS che si trova nei sorgenti del kernel.
484 Iniziare con lo sviluppo del Kernel
485 -----------------------------------
487 Sono comuni le domande sul come iniziare con lo sviluppo del kernel - sia da
492 di sviluppo iniziale. Questo, in effetti, può essere una tecnica efficace.
494 sviluppatori kernel con esperienza. È possibile anche "portare a casa"
495 sviluppatori per accelerare lo sviluppo del kernel, dando comunque
497 al datore di lavoro un gruppo di sviluppatori che comprendono sia il kernel
512 Andrew Morton da questo consiglio agli aspiranti sviluppatori kernel
516 Il primo progetto per un neofita del kernel dovrebbe essere
517 sicuramente quello di "assicurarsi che il kernel funzioni alla
521 persistenza!) ma va bene - è parte dello sviluppo kernel.
525 In assenza di problemi ovvi da risolvere, si consiglia agli sviluppatori
526 di consultare, in generale, la lista di regressioni e di bachi aperti.