Quali sono le cose buone e cattive nella progettazione del kernel Linux?

Question

Non sono un maestro del codice del kernel, ma ho un'idea di base della sua struttura di codice. In questo post possiamo discutere quali sono le cose buone e cattive nella progettazione del kernel.

Aggiornamento: No, questo non è per i compiti. Avrei detto che se fosse così.

vedere questo: https://stackoverflow.com/questions/1548442/i-know-how-to-program-now-how-do-i-learn-to-design

Ognuno loda il progetto del kernel Linux. Facciamo un elenco di decisioni di progettazione buone e cattive che sono state prese nella progettazione del kernel.

Answer 1

alcuni articoli sono denominati "Modelli di Kernel Linux Design". puoi trovare vari pattern per il kernel di progettazione per Linux. un articolo che continua è "Linux Kernel Design Patterns - Part 1", inizia da questo e googleing per l'articolo in più per Kernel Design Pattern.

Answer 2

Penso che questo http://linuxhelp.blogspot.com/2006/05/monolithic-kernel-vs-microkernel-which.html dovrebbe far luce sulla tua domanda.

Answer 3

cosa peggiore:

Il sistema di compilazione, (sì, lo so che è niente a che fare con il design del kernel stesso).
È un incubo assoluto, niente come nessun altro esistente e se per qualche motivo (aggiungendo una nuova architettura, forse) è necessario cambiarlo, allora devi imparare una lingua completamente nuova per farlo.

migliore cosa:

Quasi tutto è configurabile. È sorprendente che lo sia lo stesso kernel sia utilizzato in piccoli dispositivi embedded senza MMU e in supercomputer con enormi memorie e migliaia di processori.

Answer 4

Non direttamente sul design di Linux, ma credo che il processo di sviluppo dietro di esso sia il più degno di nota. Il kernel stesso è in continua evoluzione e lo fa con incredibile velocità. Ciò è possibile solo a causa del controllo della versione decentralizzata (git), che consente a un numero molto elevato di sviluppatori di lavorare simultaneamente.

Inoltre, con git bisect hanno compiuto qualcosa di notevole; è ora possibile per i non sviluppatori di rintracciare i bug. Ecco una citazione da David Miller:

Quello che la gente non si ottiene è che questo è una situazione in cui si applica il "nodo finale principio". Se disponi di risorse limitate a (qui: sviluppatori) , non carichi la maggior parte dell'onere . Invece sposti le cose alla risorsa che hai molto, i nodi finali (qui: utenti), in modo che la situazione venga effettivamente ridimensionata.

persone segnalare un bug hanno accesso all'ambiente in cui il bug si verifica, e "git bisect" estrarre automaticamente le informazioni rilevanti da questo ambiente. Questo è anche un buon modo per ottenere nuovi contributori.

Inoltre, ogni volta che gli sviluppatori vogliono contribuire con il codice, devono assolutamente suddividere il loro codice in minuscole patch applicabili separatamente, in modo che ogni cambiamento possa essere facilmente rivisto. In questo modo molte parti del loro codice possono essere capite da molte persone.

Linux Management Style è una lettura interessante. Linus cerca di vivere un'atmosfera in cui non ti nascondi dietro la cortesia, ma dichiari chiaramente ciò che pensi. Questo potrebbe accadere in qualcuna delle volte, ma sono sicuro che mantiene la qualità del codice ad un livello elevato.

Answer 5

cose negative:

1. nuovo tasso caratteristica è alta e il ciclo di bug fix per questo dispone di poco.
2. Il sistema di configurazione deve essere intelligente. e categorizzato per alcune esigenze generali. se ha un sistema di configurazione simile a wizard e più interazioni e informazioni durante la configurazione.
3. grande blocco del kernel e altri blocchi ovunque senza un buon meccanismo di controllo.

cose positive: driver in modalità

1. utente: modalità file system dell'utente, Driver blocco modalità utente, driver di blocco modalità utente, HID grezzo, ...
2. buon pilota di inclusione. al giorno d'oggi un'ampia gamma di dispositivi supporta il kernel di Linux.
3. virtualizzazione leggera nel kernel.
4. buoni meccanismi di comunicazione tra lo spazio utente e lo spazio del kernel (dev, proc, sys, debugfs, ...)
5. ottimo utilizzo del linguaggio C con i puntatori di funzione nelle strutture per simulare alcune delle funzioni orientate agli oggetti.
6. modalità utente linux per il debug.
7. buon supporto di sistemi embedded
8. molto buoni meccanismi di sicurezza: SELinux, AppArmor, la verifica dell'integrità, ...

Answer 6

penso di sviluppo del kernel, piuttosto che essere un problema di progettazione con sfondi filosofici e dibattiti (come ad come kernel micro-kernel rispetto a kernel monolitico), è un problema di codice pratico che funziona in modo affidabile. La varietà di periferiche e protocolli supportati da un kernel in aggiunta all'ampia gamma di versioni e produttori hardware e anche i problemi complessi che si presentano nello sviluppo in modalità protetta (rispetto allo sviluppo in modalità utente utilizzato dalle applicazioni) giustificano questa affermazione. Inoltre, non dimenticare il problema di compatibilità con le versioni precedenti, che è di vitale importanza per un sistema operativo in pratica, ma principalmente trascurato nella filosofia del design.

Il kernel Linux è un buon esempio di questo: un kernel monolitico (anche se molto modulare) con molti hack pragmatici che supera di gran lunga molti sistemi operativi accademici o commerciali ben progettati in termini di popolarità e prestazioni in entrambe le aree del server e del sistema embedded.

Un vantaggio superiore di Linux è che molti aspetti del suo kernel possono essere incorporati nell'immagine del kernel (principalmente bzImage) o aggiunti come modulo del kernel in seguito. Puoi configurarlo prima di fare l'immagine del kernel usando lo strumento config e quindi qualsiasi modulo del kernel può essere facilmente rimosso o aggiunto in fase di runtime (ovviamente tramite privilegio di root) senza dover riavviare il sistema operativo. Ciò facilita lo sviluppo e la manutenzione del kernel.(Basti pensare al sistema operativo Windows che ha bisogno di un riavvio per quasi tutti gli aggiornamenti, molte volte nei programmi non correlati a kernel)