chiarimenti sviluppo kernel

Postate qui per tutte le discussioni legate a Linux in generale.

Moderatore: Staff

Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Rispondi
Avatar utente
Luke88
Linux 3.x
Linux 3.x
Messaggi: 624
Iscritto il: mer 7 set 2005, 0:00
Slackware: 13.0
Kernel: 2.6.30-zen4
Desktop: xfce4
Località: Udine

chiarimenti sviluppo kernel

Messaggio da Luke88 »

volevo aprire questo post per provare a chiarire il processo di sviluppo che sta dietro al kernel serie 2.6, perchè mi sembra ci sia un po' di confusione e perchè anche io non ho capito troppo bene...

a me sembra che l'idea del ramo di transizione sia stata abbandonata completamente...

da quello che ho capito leggendo su riviste varie (quello che scrivo qui l'ho preso da linux pro), il problema era che quelle nuove funzioni, mancanti nel 2.4, venivano "backportate" dal 2.5 al 2.4, creando problemi, da molte distro (RH e SUSE erano le nominate), e questo ha allontanato la serie 2.6 di più di 2 anni...

dopo il rilascio del 2.6, venivano integrate nuove funzioni anche pesanti, instabli, quasi direttamente nel ramo stabile. si è risolto definendo "stabili" i kernel rilasciati (tipo 2.6.13) e in sviluppo gli rc.

il secondo problema che si notò era che erano relativamente pochi a testare le nuove funzioni.
si è risolto arrivando al sistema attuale:
il kernel stable subisce una fase di revisione pubblica, che ha inizio quando il mantainer pensa di avere abbastanza modifiche. le proposte sono inviate alla mailing list, e se nessuno ha qualcosa da controbattere, vengono accettate.
poi viene rilasciata una release "candidata", a cui non può essere aggiunto niente, ma solo correzioni.

quando è ritenuto stabile, viene rilasciato.

le nuove regole per lo sviluppo di un kernel stabile sono:

Codice: Seleziona tutto

1-la modifica deve essere palesemente testata e corretta
2-la modifica non deve superare le 100 linee di codice
3-la modifica deve correggere 1 solo problema
4-la modifica deve correggere bug reali con problemi per gli utenti, non "potenziali"
5-la modifica deve riguardare problemi critici
6-non si accettano correzioni a "race condition teoriche" (questa poi me la spiegate :P)
7-la modifica non deve contenere correzioni estetiche (errori ortografia ecc...)
8-la modifica deve essere accettata dal mantainer del sottosistema interessato
avete qualcosa da aggiungere? potete confermare quello che ho riportato?
Luke
Meeting efficency = Average_Intelligence/( Number_Of_People^2 )

Avatar utente
IceSlack
Linux 4.x
Linux 4.x
Messaggi: 1313
Iscritto il: dom 30 ott 2005, 13:27

Messaggio da IceSlack »

cos ami significa che non puo' superare le 100 linee di codice.................. a me smebra una vera *****

la modifica deve correggere 1 solo problema

non e' possibile :shock: e s ene ha 30 ?

mha se e' vero inizia a schifarmi sto modo di sviluppo

Avatar utente
DaNiMoTh
Linux 3.x
Linux 3.x
Messaggi: 941
Iscritto il: mar 30 nov 2004, 0:00
Località: irc.syrolnet.org /// #slackware
Contatta:

Messaggio da DaNiMoTh »

Le 100 linee di codice sono il limite perche` andando oltre potrebbero cambiare molte cose che magari ad una prima occhiata possono sfuggire ( stiamo parlando di una release candidata ).

La modifica corregge un solo problema; per gli altri 29 si fanno altrettante modifiche, cosi` quando qualcosa non va si sa cosa l'ha provocato.

first
Linux 3.x
Linux 3.x
Messaggi: 677
Iscritto il: gio 23 giu 2005, 0:00

Messaggio da first »

ue luke aggiungi confusione a confusione :D
in un mio "storico" post credo di aver chiarito molti punti oscuri nella gestione dello sviluppo del kernel linux. Comunque datti anche una occhiata alle faq di kernel.org .
Le regole che hai esposto, alla luce delle faq, sono da intendersi come contributi "standard" al kernel cioe' se rispetti quelle regole puoi mandare la tua modifica ad un responsabile di una sotto sezione del kernel. Se le modifiche invece sono piu' corpose allora la procedura non e' piu quella standard ma devi mandarle direttamente al "boss" Linus.

Rispondi