Questo \u00e8 un articolo decisamente pi\u00f9 tecnico di quelli a cui vi ho abituato, specie in questa categoria, tuttavia pu\u00f2 essere interessante anche per i non addetti ai lavori pi\u00f9 curiosi.<\/p>\n
Si parla delle origini del kernel Linux, ma non come semplice e piacevole aneddoto: quello potete leggerlo pressoch\u00e9 su ogni articolo su Linux. Ho trovato da qualche parte su Internet i sorgenti del primissimo rilascio di Linux, la versione 0.01 e ho pensato che potrebbe essere interessante dargli un’occhiata e commentare i principi che hanno portato alla nascita del pinguino pi\u00f9 famoso del mondo! Ecco, per l’appunto, la traduzione di alcuni punti salienti delle note di rilascio. Uso una sezione codice, cos\u00ec il testo si potr\u00e0 scorrere senza creare un messaggio lunghissimo! Questa versione ha principalmente scopi di lettura – per esempio se sei interessato a come il sistema appare al momento.\u00a0 Verr\u00e0 compilato e produrr\u00e0 un kernel funzionante, ma anche se potr\u00f2 aiutare come potr\u00f2 a farlo funzionare sulla tua tua macchina (scrivimi via mail), non \u00e8 propriamente supportato. I cambiamenti sono frequenti e la prima versione “di produzione” forse differir\u00e0 parecchio da questo rilascio pre-alpha.<\/p>\n Hardware richiesto per eseguire linux: La tastiera finlandese \u00e8 fortemente cablata e dato che non ne ho una americana non posso cambiarla senza grossi problemi. Vedi kernel\/keyboard.s per i dettagli. Se qualcuno fosse disposto a fare un port anche parziale, gli sarei grato. Non dovrebbe essere troppo difficile, dato che \u00e8 guidato da tabelle (\u00e8 assembler, comunque, quindi…)<\/p>\n Sebbene linux sia un kernel completo e non usi codice di minix o altri sorgenti, quasi nessuna delle routine di supporto \u00e8 stata ancora codificata. Quindi al momento ti serve minix per avviare il sistema. Dovrebbe essere possibile usare il disco dimostrativo gratuito di minix per creare un filesystem e far girare linux senza avere minix, ma non so…<\/p>\n […]<\/p>\n 3. Breve panoramica tecnica del kernel<\/p>\n Il kernel linux \u00e8 stato fatto sotto minix e la mia idea originale era dargli compatibilit\u00e0 binaria con minix. Quest’idea \u00e8 stata abbandonata, dato che le differenze sono cresciute, ma il sistema ancora somiglia molto a minix. Alcuni dei punti chiave sono:<\/p>\n – Uso efficiente delle possibilit\u00e0 offerte dal chip 386. – Nessun passaggio di messaggi, questo \u00e8 un approccio pi\u00f9 tradizionale a unix. Le chiamate di sistema solo solo questo: chiamate. Questo pu\u00f2 o no essere pi\u00f9 veloce, ma significa che possiamo evitare molti dei problemi coi messaggi (code di messaggi, ecc). Certamente, perderemo anche le belle caratteristiche :-b.<\/p>\n – Filesystem multithread – una differenza diretta del non utilizzare messaggi. Questo rende il filesystem un po’ (molto) pi\u00f9 complicato, ma pi\u00f9 carino. Accoppiato con uno scheduler migliore, significa che puoi effettivamente eseguire processi in modo concorrente senza le perdite di performance indotte da minix.<\/p>\n – Cambio di task minimo. Anche questa \u00e8 una conseguenza del non usare messaggi. Cambiamo task solo quando vogliamo farlo, diversamente da minix che cambia task qualsiasi cosa tu faccia. Questo significa che possiamo implementare pi\u00f9 facilmente implementare il supporto a 387 (infatti questo \u00e8 gi\u00e0 in buona parte implementato). – Gli interrupt non sono nascosti. Molte persone (fra le quali Tanenbaum) pensano che gli interrupt siano brutti e dovrebbero essere nascosti. Non secondo me. In seguito a ragioni pratiche, gli interrupt devono essere gestiti da codice macchina, che \u00e8 un peccato, ma sono una parte del codice come tutte le altre. Specialmente i driver sono per lo pi\u00f9 routine degli interrupt – vedi kernel\/hd.c, ecc.<\/p>\n – Non c’\u00e8 distinzione fra kernel, filesystem e gestore della memoria, sono tutti linkati all’interno dello stesso codice. Questo ha lati positivi e negativi. Il codice non \u00e8 modulare come quello di minix, ma d’altra parte alcune cose sono pi\u00f9 semplici. Le differenti parti del kernel sono sotto differenti sottodirectory nell’albero dei sorgenti, ma quando vengono eseguite tutto avviene nello stesso spazio di codice e dati.<\/p>\n Le linee guida nell’implementazione di linux erano: renderlo presto funzionante. Volevo che il kernel fosse semplice, anche se potente abbastanza per eseguire molto del software unix. Riguardo al filesystem non ho potuto fare molto – doveva essere compatibile con minix per ragioni pratiche e il filesystem di minix era semplice abbastanza cos\u00ec com’era. Il kernel ed il gestore di memoria potevano essere semplificati, comunque:<\/p>\n – Una sola struttura dati per i task. I “veri” unix hanno le informazioni sui task in vari posti, io volevo tutto in un solo posto.<\/p>\n – Un algoritmo di gestione della memoria molto semplice che usasse sia la paginazione che la segmentazione offerte dal 386. Attualmente il gestore della memoria occupa solo due files: memory.c e page.s, solo un paio di centinaia di linee di codice.<\/p>\n Queste decisioni sembrano aver funzionato bene. I bug sono stati facili da individuare e le cose funzionano.<\/p>\n […]<\/p>\n<\/div>\n<\/blockquote>\n<\/div>\n Ci\u00f2 che \u00e8 chiaro sin dall’inizio \u00e8 che a Linus interessava esplorare le possibilit\u00e0 del suo nuovo processore 80386 e di sperimentarle scrivendo il suo kernel. Traspare anche una certa insoddisfazione verso MINIX, che allora era alla sua prima versione e aveva molte limitazioni imposte dalla retrocompatibilit\u00e0 con gli intel 8088, ma anche dall’esigenza di mantenersi semplice per i suoi utilizzi didattici. Inoltre possiamo notare come le idee di Torvalds differiscano da quelle di Tanenbaum (professore e principale autore di MINIX). Il secondo \u00e8 un vivo sostenitore dell’approccio a microkernel per la scrittura dei sistemi operativi, nonch\u00e9 della stratificazione del software, mentre Linus segue l’approccio classico del kernel monolitico. Con un microkernel i servizi del sistema operativo vengono offerti da processi separati che comunicano fra loro attraverso messaggi, mentre in un kernel monolitico sono forniti da una serie di procedure compilate tutte insieme, senza una vera separazione, cos\u00ec che non c’\u00e8 bisogno di scambio di messaggi. I principi che hanno portato alla nascita di Linux sono quindi, in sostanza, la creazione di un kernel che sfruttasse a pieno il processore 386 e che funzionasse subito! Diamo ora uno sguardo al codice, senza addentrarci troppo nei dettagli. Si conclude questo nostro piccolo viaggio nella prima incarnazione di Linux, oggi divenuto uno dei sistemi pi\u00f9 utilizzati al mondo (su varie architetture, nonostante le premesse!). Spero che i lettori abbiano gradito questa mia versione della nascita del nostro amato pinguino, se non altro perch\u00e9 la storia del ragazzo che scrive un kernel per divertimento e completa inconsapevolmente il sistema GNU l’abbiamo sentita e risentita in tutte le salse! Spero anche di aver reso le parti tecniche ragionevolmente comprensibili anche per persone poco pratiche. Di osservazioni se ne potrebbero fare altre mille, ma diventerebbe un post troppo tecnico, mentre la mia intenzione era regalarvi questa “curiosit\u00e0”. Se qualcuno poi scaricasse il codice e volesse saperne di pi\u00f9, risponder\u00f2 con piacere a richieste di chiarimenti.<\/p>\n Finisco con una simpatica citazione di un commento all’interno del codice sorgente:<\/p>\n Non \u00e8 forse cos\u00ec che funziona il software libero?<\/p>\n","protected":false},"excerpt":{"rendered":" Questo \u00e8 un articolo decisamente pi\u00f9 tecnico di quelli a cui vi ho abituato, specie in questa categoria, tuttavia pu\u00f2 essere interessante anche per i non addetti ai lavori pi\u00f9 curiosi. Si parla delle origini del kernel Linux, ma non … Continua a leggere
\nVisto che la licenza lo consente, anche se ancora non era la nostra amata GNU GPL, ho pubblicato l’archivio originale col kernel. Mancano i file a corredo, in primis la shell bash compilata, ma tanto difficilmente qualcuno si metter\u00e0 a compilare i sorgenti cos\u00ec come sono! Sono invece intatte le note di rilascio originali che vi traduco in parte per la nostra piccola analisi!
\nClicca qui per scaricare il file<\/a><\/p>\n
\nPerdonatemi se la traduzione non sar\u00e0 perfetta (correzioni sono ben accette), ma il significato comunque sar\u00e0 intatto.<\/p>\n\n
\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 1. Breve introduzione<\/code><\/code>Questo \u00e8 un kernel minix-like gratuito per macchine AT basate su i386(+). \u00c8 incluso il sorgente completo e questo sorgente \u00e8 stato usato per produrre un kernel funzionante su due macchine differenti. Al momento non ci sono binari del kernel per una visualizzazione pubblica, dato che devono essere ricompilati per macchine differenti. Devi compilarli con gcc (io uso l’1.40, non so se l’1.37.1 gestir\u00e0 tutte le direttive __asm__), dopo aver cambiato i file di configurazione rilevanti.Come il numero di versione (0.01) suggerisce, non \u00e8 un progetto maturo.
\nAttualmente \u00e8 supportato solo un sottoinsieme dell’hardware AT (hard disk, schermo, tastiera e linee seriali) ed alcune delle chiamate di sistema non sono ancora state pienamente implementate (in particolare mount\/umount non sono ancora state implementate). Vedi i commenti o i readme nel codice.<\/p>\n
\n– AT 386
\n– Schermo VGA\/EGA
\n– Controller per hard disk tipo AT (IDE va benissimo)
\n– Tastiera finlandese (oh, puoi usare una tastiera americana, ma non senza una certa pratica \ud83d\ude42<\/p>\n
\nMinix \u00e8 stato scritto su un 8088 e successivamente portato su altre macchine – linux si avvantaggia totalmente del 386 (che una buona cosa se hai un 386, ma rende il porting molto difficile)<\/p>\n
\n[il 387 era un coprocessore progettato per lavorare in coppia col processore 386, ndt]<\/p>\n
\nCiascuno dei due approcci ha vantaggi e svantaggi e ha generato vari dibattiti, fra cui quello pi\u00f9 noto fra gli stessi Tanenbaum e Torvalds. Purtroppo questo dibatitto, che di per s\u00e9 era interessante \u00e8 iniziato col piede sbagliato, dal momento che Tanenbaum, persona molto competente e dotata di un certo senso dell’umorismo, defin\u00ec Linux “obsoleto” in partenza, proprio per l’approccio pi\u00f9 classico scelto da Linux. Vedi qui<\/a>.<\/p>\n
\nIl rapido raggiungimento di questi obiettivi ha decretato il successo di Linux: i PC IBM, successori e cloni erano (e sono tutt’ora) la scelta ideale per chi voleva un computer in casa senza spendere una fortuna, ma BSD e Hurd sono nati su macchine diverse, inoltre il primo aveva problemi legali da affrontare ed il secondo era enormemente instabile. Linux era costruito intorno al 386 e non intorno all’8088 come MINIX o l’MS-DOS, era un kernel Unix-like, era libero e funzionava! Un hobbista non poteva chiedere di meglio.<\/p>\n
\nAprendo qualche file a caso nella directory kernel (nome fuorviante, dato che in realt\u00e0 tutto fa parte del kernel. Qui ci sono le parti pi\u00f9 centrali, come la gestione degli interrupt e lo scheduler) ci accorgiamo che il codice C \u00e8 misto a codice assembly. Per chi non fosse pratico, il linguaggio assembly \u00e8 quello pi\u00f9 legato al linguaggio macchina, quindi diverso da un tipo di processore all’altro. Normalmente il codice dipendente dalla macchina viene messo in file separati, in modo da poterlo sostituire facilmente se si ricompila il sistema per un’architettura diversa (un esempio tipico dei giorni nostri \u00e8 il passaggio dai 32 ai 64 bit delle CPU Intel), mentre in questo caso \u00e8 tutto insieme, il che elimina l’overhead delle chiamate alle routine separate, ma rende il codice meno portabile, altro aspetto criticato da Tanembaum e comunque eliminato in seguito.
\nUn altro evidente esempio sia del legame stretto con l’architettura Intel 386 che della natura monolitica di Linux \u00e8 nel file kernel\/hd.c: questo file \u00e8 di fatto un driver per dischi IDE, ma vi \u00e8 anche parte della gestione degli interrupt del disco stesso e qualche riferimento al filesystem. Normalmente la gestione dell’I\/O avviene in pi\u00f9 strati per supportare diversi dispositivi e, nel caso dei dischi, diversi filesystem, fornendo all’utente un’interfaccia comune. Oggi come oggi difficilmente un driver \u00e8 compilato insieme al kernel ed anche nei sistemi monolitici di solito \u00e8 un modulo separato.. il kernel sarebbe enorme per gestire tutti i dispositivi possibili! Tutto questo in quel momento non era previsto per Linux: dobbiamo tener conto che si trattava di qualcosa scritto per divertimento e che, anche se il kernel resta monolitico, oggi le cose sono diverse ed organizzate meglio!<\/p>\n\n
\n\/*
\n* Wirzenius wrote this portably, Torvalds fucked it up \ud83d\ude42
\n*\/<\/div>\n<\/blockquote>\n