1

Parte 3: Dettagli del kernel Linux(https://www.youtube.com/watch?v=Imbxqv_5TJU)

2

Lezione 16Analisi del codiceSistemi Operativi (9 CFU), CdL Informatica, A. A. 2020/2021Dipartimento di Scienze Fisiche, Informatiche e MatematicheUniversità di Modena e Reggio Emiliahttp://weblab.ing.unimo.it/people/andreolini/didattica/sistemi-operativi

http://weblab.ing.unimo.it/people/andreolini/didattica/sistemi-operativi

3

Quote of the day(Meditate, gente, meditate...)

“UNIX gives you just enough rope to hang yourself – and then a couple more feet, just to be sure. ”

Eric Allman (1955-)ProgrammatoreAutore di Sendmail e Syslog

4

Lo scenario(Lo studente vuole approfondire l’API messa a disposizione in GNU/Linux)

Lo studente vuole approfondire la conoscenza del kernel Linux, principalmente per capire come sono implementati i servizi offerti alle applicazioni.

5

Interrogativi(Quali strumenti di analisi del codice esistono? A che servono?)

Lo studio dei meccanismi offerti dal kernel e dalle librerie di base richiede familiarità con gli stru-menti di navigazione ed analisi del codice.Quali strumenti esistono?Quali operazioni consentono di svolgere? Linux kernel

source

GNU C librarysource

Analysistools

Applicationsource

6

INTRODUZIONE

7

Scenario e interrogativi(Come è organizzato un SO? Come funzionano le chiamate di sistema?)

Scenario: lo studente, triste perché non può seguire altri tre mesi di “Sistemi Operativi”1, vorrebbe capire i rudimenti dell’analisi del codice.

Interrogativi:Come è articolata in generale la procedura di analisi del codice?Quanto è complicata?

1Pare vero…

8

Che cosa si intende esattamente?(Per “analisi del codice”)

L'analisi del codice è quell'insieme di tecniche mediante le quali un programmatore studia il codice sorgente di una applicazione. Essa consta di diverse fasi:

individuazione della versione del software;recupero del codice sorgente;creazione di un albero sorgente;indicizzazione dell'albero sorgente;navigazione semplificata dell'albero sorgente.

9

Che obiettivi persegue?(Sempre lei, l'analisi del codice)

Gli obiettivi dell'analisi del codice sono molteplici ed evidenti:

capire come è strutturata una applicazione;capire che cosa fa una determinata funzione;capire quali funzioni (di libreria e del SO) sonoinvocate da una specifica funzione.

Quest'ultimo punto è cruciale per scovare i motivi di non conformità funzionale, prestazionale e di sicurezza.

10

Quali software vanno analizzati?(Massimizziamo il profitto con il minimo sforzo)

Per (iniziare a) comprendere in maniera approfondita (non “a favoletta”) le dinamiche di un SO è importante imparare ad analizzare i seguenti software.

Kernel (il software che media l'accesso alle risorsehw/sw della macchina).Libreria del C.Utility di sistema.

Tutto il resto è opzionale e complementa la vostra preparazione.

11

Quanto è difficile?(Analizzare kernel, libreria del C, utility di sistema)

È molto difficile. Il codice esibito da questi software è ottimizzato, ha una struttura complessa, usa tutte le funzionalità extra del compilatore C.In questo corso introduttivo saranno mostrati in modalità “spot” alcuni cenni implementativi, per far capire come muoversi nei meandri del SO.Chi vuole veramente crescere, dovrà affrontare il toro per le corna. Ciò a prescindere da corso, esame e voto.

12

La curva abilità-sforzo(AKA “Più si diventa bravi, più è difficile migliorarsi ulteriormente”)

Abilità

Sforzo

Abilità limitedi una persona

Incapacità

Ozio Stacanovismo

Abilità = (1 – e-Sforzo) * Abilità_max

Miglioramento

Sforzofatto

Miglioramento

Sforzofatto

13

La morale(“Shut up and squat!”)

14

VERSIONI DEL SOFTWARE

15

Scenario e interrogativi(Come sono strutturati i numeri di versione di un software?)

Scenario: lo studente, pur armato di buona volontà, si blocca subito nelle attività di scaricamento perché si rende conto che i pacchetti software sono corredati di numeri di versione strani.

Interrogativi:Come sono decisi i numeri di versione di un software?Lo schema dei numeri di versione è univoco o ne esistono diversi?

16

Le versioni del software(Caratterizzano ogni singolo rilascio)

Ciascun rilascio (release) di software è etichettato con un numero di versione che lo caratterizza in maniera univoca.Il numero di versione è una stringa alfanumerica che obbedisce ad un preciso schema.Conoscere lo schema dei nomi di versione di un dato software è la prima cosa da fare, poiché:

permette di capire se una versione è l'ultima o no.permette di capire se una versione è “stabile” o disviluppo.

17

Lo schema GNU(Usato dalla libreria del C e dalle utility di sistema)

Il numero di versione dei software GNU è, in linea di massima, caratterizzato da una stringa del tipo:

major.minorMajor: numero principale di revisione. Se aumenta, si è in presenza di importanti modifiche nel software.Minor: numero secondario di revisione. Se aumenta, si è in presenza di correzioni puntuali nel software.

18

Lo schema del kernel(Usato dal kernel (who else?))

Lo schema dei numeri di versione del kernel è stato molto più travagliato. Si guardi qui:

http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering

Questo vuol forse dire che i programmatori del kernel sono matti, masochisti, cretini?Assolutamente no! Il kernel è rilasciato in molteplici versioni (stabile o di sviluppo) per soddisfare le esigenze dei singoli consumatori (hacker incalliti, distributori di GNU/Linux, segretari, videogiocatori, studenti, etc…).

http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering

19

Primo schema: stile GNU(Versioni 0.01 – 1.0)

Il primo schema utilizzato rappresenta la versione come una stringa major.minor, esattamente come nel progetto GNU.

Versioni 0.01, 0.02, 0.03, 0.10, 0.11, 0.12, 0.95, 0.96,0.97, 0.98, 0.99, 1.0.

Problema: quali versioni sono le più importanti? Dallo schema non si capisce nulla sullo stato del codice sorgente.

20

Secondo schema: odd-even(Versioni 1.0 – 2.6.0)

Il secondo schema utilizzato rappresenta la versione come una stringa del tipo:major.minor.revision.

revision indica un nuovo rilascio con fix relativi afunzionalità, prestazioni, sicurezza.minor dispari indica una versione di sviluppo (ad es.(v2.1.3, v2.3.18).minor pari indica una versione stabile da includerenelle distribuzioni GNU/Linux (ad es., v2.2.22, v2.4.20).major cambia in seguito a miglioramenti epocali.

21

Problema del secondo schema(Il ciclo di sviluppo è troppo lungo)

L'intervallo temporale fra un ciclo di sviluppo ed il successivo ciclo di stabilità è enorme: diversi anni.Questo è il tempo che bisogna aspettare per:

migliorare le prestazioni di aree critiche del kernel.introdurre nuovi driver dei dispositivi.introdurre nuovi algoritmi di compressione o dicrittografia.

Una distribuzione GNU/Linux non è in grado di integrare rapidamente il kernel con gli altri software.

22

Terzo schema: time-based(Versioni 2.6.0 -)

Il terzo schema utilizzato rappresenta la versione come una stringa del tipo:major.minor.revision.

revision indica una nuova versione anche conmodifiche importanti.minor cambia in seguito a modifiche importanti.major cambia in seguito a modifiche moltoimportanti.

23

Problema del terzo schema(Non è ben chiara la differenza fra major e minor)

Il primo problema del terzo schema è la mancanza di chiarezza fra major e minor.È lasciato a Linus Torvalds l'arduo compito di stabilire se e come vale la pena di incrementare major e minor.Torvalds stesso, non credendo in tale schema, ad un certo punto ha incrementato la versione del kernel da 2.6.39 a 3.0.

24

Problema del terzo schema(Come gestire i fix importanti?)

Il secondo problema del terzo schema è la completa assenza di un meccanismo per distinguere distribuzioni stabili da quelle in via di sviluppo.Nel kernel 2.6.8 un baco al Network File System ha richiesto il rilascio urgente di una nuova versione con il fix relativo.Torvalds ha rilasciato non la versione 2.6.9, bensì la 2.6.8.1.

→ Uso di un quarto numero per contare il numero di “fix” ad una specifica versione del kernel.

25

Lo schema in uso oggi(Time-based, trimestrale, con differenziazione stabile-sviluppo)

Lo schema in uso oggi riflette da vicino il ciclo di sviluppo di una specifica versione del kernel.Tale ciclo dura tre mesi e comincia con due settimane in cui Torvalds raccoglie tutte le modifiche fatte dagli sviluppatori (merge window).

5.9

Merge window(2 settimane)

26

Lo schema in uso oggi(Time-based, trimestrale, con differenziazione stabile-sviluppo)

Al termine della merge window viene rilasciata la prima versione candidata (release candidate).Il suo numero di versione è pari alla versione successiva (5.10) seguita da una stringa “-rc1”.Gli utenti sono incoraggiati a provarla e a segnalare ogni tipo di difetto.

5.9

5.10-rc1

Rilascio rc1(1 settimana)

27

Lo schema in uso oggi(Time-based, trimestrale, con differenziazione stabile-sviluppo)

Nelle settimane successive sono rilasciate ulteriori release candidate, ed il processo di sviluppo continua con le stesse modalità.Ci si auspica che le modifiche successive siano sempre più confinate e contenute.

5.9

5.10-rc1

5.10-rc2

5.10-rc7

Rilascio rc7(7 settimane)

...

28

Lo schema in uso oggi(Time-based, trimestrale, con differenziazione stabile-sviluppo)

Dopo un numero variabile di iterazioni (Cinque? Sette? Nove?) Torvalds decide di rilasciare la nuova versione.→ Compromesso tra stabilità del kernel, raggiungimento degli obiettivi e “time to release” (obiettivo: tre mesi per una release).

5.9

5.10-rc1

5.10-rc7

Rilascio nuova versione(~ 3 mesi)

...

5.10

29

Lo schema in uso oggi(Time-based, trimestrale, con differenziazione stabile-sviluppo)

Il ciclo si ripete con la nuova versione.Merge window.Rilascio rc.…

5.9

5.10-rc1

5.10-rc7

...

5.10

5.11-rc1

30

Lo schema in uso oggi(Time-based, trimestrale, con differenziazione stabile-sviluppo)

In parallelo al ciclo di sviluppo del kernel v5.10, un altro sviluppatore del kernel (scelto fra N volontari) crea le versioni stabili del kernel v5.9.Ogniqualvolta viene segnalato un importante baco nel kernel 5.9 già rilasciato, si produce un fix e si rilascia una versione 5.9.1.

5.9

5.10-rc1

5.10-rc7

...

5.10

5.11-rc1

5.9.1

5.9.2

...

5.9.6

31

Long Term Kernel(I kernel forniti dai distributori GNU/Linux)

Alcune specifiche versioni del kernel sono battezzate Long Term. A ciascuna di esse è assegnato uno sviluppatore responsabile per la creazione di release stabili.A differenza delle normali release stabili, i Long Term Kernel devono durare per alcuni anni, fino alla fine del loro ciclo di vita (End Of Live).Questi sono i kernel tipicamente pacchettizzati dalle distribuzioni GNU/Linux.

https://www.kernel.org/category/releases.html

https://www.kernel.org/category/releases.html

32

Le versioni del distributore(Come se non bastasse!)

In tutto questo marasma interviene ovviamente anche il distributore (nel nostro caso, Debian).Debian sceglie alcune versioni ben specifiche dei pacchetti ed estende il numero di versione upstream con il proprio contributo.

33

Il nome dei pacchetti Debian(Possono non coincidere con i nomi dati da upstream; tragedia!)

I nomi dei pacchetti software distribuiti da Debian possono essere diversi rispetto a quelli di upstream. Seguono alcuni esempi notevoli.Il kernel viene chiamato linux da upstream e linux-image da Debian.La libreria del C viene chiamata glibc da upstream e libc6 da Debian.

34

Il numero di versione Debian(Come differisce dall'upstream?)

Il numero di versione di Debian segue uno schema decisamente complicato. Per conoscere l'amara verità:

https://www.debian.org/doc/debian-policy/ch-controlfields.htmlAd esempio, in una delle versioni di Debian Wheezy il numero di versione della libreria del C era 2.13-38+deb7u4:

“2.13” → la versione upstream di GNU libc.”38” → il numero di revisione Debian (quanti

pacchetti con correttivi sono usciti per laversione 2.13).

“+deb7” → Debian 7 (Wheezy).“u4” → Quarto upload fatto con urgenza da uno

sviluppatore che NON è il maintainer (NonMaintainer Upload, NMU).

https://www.debian.org/doc/debian-policy/ch-controlfields.html

35

Complicato?(Abbastanza!)

Gli schemi visti finora sembrano complicati?Si tenga presente che, per semplificare le cose, nella descrizione svolta finora sono stati omessi alcuni aspetti.Si tenga anche presente che il workflow non è scolpito nella pietra, ma può cambiare anche repentinamente, se gli sviluppatori lo ritengono opportuno.

36

Orrore!(“Mi parve di vedere un quadro, ma dopo qualche minuto non c'era più.”)

37

RECUPERO DEL CODICE SORGENTE

38

Scenario e interrogativi(Come si scarica un archivio sorgente?)

Scenario: lo studente sa ora riconoscere il software più adatto ai suoi scopi a partire dal numero di versione corrispondente. Ora vorrebbe imparare a scaricare un archivio sorgente per poi poterlo spacchettare e studiare.

Interrogativi:Come si scarica un archivio sorgente?

39

Formati di distribuzione dei sorgenti(Questo dovrebbe già essere noto)

Archivio compresso UNIX. È un singolo file contenente l'albero di una versione specifica del progetto software, compresso opportunamente (LZ77, Burrows-Wheeler, …).

Repository software. È una directory contenente una versione specifica del progetto software e le informazioni necessarie per recuperare altre versioni.

CVS, SVN, GIT.

40

Un esempio concreto(Cominciamo piano piano)

Si supponga di voler scaricare il software di esempio GNU hello che mostra un messaggio di benvenuto.L'obiettivo dichiarato delle prossime slide è quello di insegnare a scaricare il codice sorgente con le tecniche più note.

41

Identificazione del numero di versione(Dovreste saperlo trovare)

Il primo passo è quello di identificare la versione di GNU hello installata sulla propria macchina.Ah, GNU hello non è installato? Lo si installi!

apt install helloChe versione è installata?

apt show helloSi legga il valore del campo “Version”: sulla macchina del docente, il numero di versione è 2.10-2.

42

Recupero manuale dell'archivio(Dalla home page del progetto)

Si legga il valore del campo “Homepage” che contiene l'URL della home page del progetto.Attualmente, l'URL è:

http://www.gnu.org/software/hello/

Si individui la pagina di download e si scarichi l'archivio hello-2.10.tar.gz.Questa è la versione upstream più vicina a ciò che usa Debian Buster. Il software fornito da Debian potrebbe avere alcune modifiche, applicate dal distributore.

http://www.gnu.org/software/hello/

43

Scompattazione dell'archivio(Si usa il comando tar, qualora ve ne foste dimenticati…)

L'archivio compresso viene estratto con il comando tar:

tar -z -x -f hello-2.10.tar.gz

Formato dicompressione

Gailly-Adler(.gz)

Estrazione Specifical'archivio

Il nomedell’archivio

44

Il risultato(Una directory contenente l'albero sorgente)

Il risultato dell'operazione è un albero sorgente contenuto nella directory hello-2.10.La sottodirectory src contiene il codice sorgente di interesse.L'intera procedura è riproducibile su qualsiasi distribuzione GNU/Linux (non è necessario avere un SO Debian sottomano).

45

Recupero automatico dell'archivio(Con gli strumenti della distribuzione Debian)

Se si dispone di un SO Debiam è possibile scaricare direttamente l'esatta versione del software con il seguente comando:

apt source helloOCCHIO: si esegua questo comando in un'altra directory, perché altrimenti si potrebbe sovrascrivere la directory hello-2.10 (ottenuta spacchettando l’archivio sorgente scaricato dal sito di GNU).

46

Che cosa succede esattamente?(Debian svolge tutto il lavoro precedente per noi)

APT scarica l'archivio sorgente upstream:hello_2.10.orig.tar.gzAPT scarica l'archivio contenente gli script per la costruzione di un pacchetto binario:hello_2.10-2.debian.tar.gzIn generale (non in questo caso) è scaricato anche un archivio contenente le modifiche apportate da Debian al software originale. Non è questo il caso.

→ Se ne deduce che GNU hello di Debian sia identico a quello fornito da upstream.

47

Il risultato(Una directory contenente l'albero sorgente corretto e con gli script di Debian)

Il risultato dell'operazione è un albero sorgente contenuto nella directory hello-2.10.L'albero differisce in due modi dalla versione upstream:

contiene le modifiche di Debian.contiene la directory debian con gli script per lacostruzione di un pacchetto binario.

È preferibile scaricare sempre l'esatto albero sorgente del software eseguito sulla distribuzione.

48

Esercizio 1 (2 min.)Scaricate il codice sorgente del pacchetto software contenente le “utilità GNU essenziali”.

49

Esercizio 2 (4 min.)Scaricate il codice sorgente del pacchetto software contenente la libreria del C.

50

Esercizio 3 (4 min.)Scaricate il codice sorgente del pacchetto software riguardante il kernel Linux.

51

Recupero di versioni diverse(Mediante software di controllo delle revisioni)

Per alcuni pacchetti software (classico esempio: il kernel) è desiderabile svolgere ulteriori operazioni sul codice:

recuperare l'ultimissima versione (più performante,più sicura e funzionante su più periferiche).controllare le differenze fra due specifiche versioni(per capire cosa cambia, ad esempio, fra quella attualee l'ultima).

Ciò è possibile scaricando un albero sorgente mantenuto sotto controllo di revisione. Il software più popolare per il controllo delle revisioni è GIT:

http://git-scm.com

http://git-scm.com/

52

GIT vs. SVN: a crash course(https://www.youtube.com/watch?v=4XpnKHJAok8)

Crash course per chi ha studiato SVN e vuole impratichirsi con GIT in una giornata:

http://git.or.cz/course/svn.html

Se non avete ancora installato GIT, correte subito ai ripari!

http://git.or.cz/course/svn.html

53

Esercizio 4 (2 min.)Identificate il nome del pacchetto Debian contenente il sistema di controllo delle revisioni GIT.Installate tale pacchetto Debian.

54

Individuazione di un repository GIT(Che cosa occorre cercare: un comando di scaricamento del repository)

Si individua inizialmente il repository GIT di GNU hello. Dalla pagina del progetto GNU:

http://www.gnu.org/software/hello/

Si individua la pagina contenente i dettagli del progetto software (il link “Hello Project Page”).Si clicca il link della “Hello Project Page” e si attende il caricamento della pagina.Si clicca il link “Source Code Manager: Git repository”.

http://www.gnu.org/software/hello/

55

Scaricamento di un repository GIT(Si usa il comando git clone)

La pagina Web appena caricata contiene le istruzioni necessarie per scaricare il repository GIT. Occorre dare il comando seguente:git clone https://git.savannah.gnu.org/git/hello.git/

Il repository si trova nella directory hello, e contiene la linea di sviluppo (detta branch) principale del software (detta master; analoga al trunk di SVN).Nella sottodirectory .git è contenuta la struttura dell'intero repository.

56

Esercizio 5 (3 min.)Si scarichi il repository GIT di coreutils.

57

Le diverse ramificazioni del progetto(Si us il comando git branch)

Un progetto ha tipicamente più ramificazioni (branch). Per capire quali sono si può dare il comando seguente:

git branch

1 4 9

2 3

5 8 10

Branchmaster

GNU Hello ha una sola linea di sviluppo esposta pubblicamente, quella principale (master).

Branchsviluppo

58

Le etichette(Si usa il comando git tag)

È buona prassi etichettare il commit che completa una versione, per poterla facilmente consultare in seguito. Il comando seguente stampa tutte le etichette (tag):

git tag

1 4 9

2 3

5 8 10

Branchmaster

Branchsviluppo

V2.7 V2.8

Tagversione 2.7

Tagversione 2.8

59

I commit(Identificati da un hash)

Una singola modifica al software, detta commit, rappresenta un insieme di cambiamenti (changeset) fatti a diversi file. Ogni commit è identificato da un hash SHA1. Per vedere la storia dei commit e le relative modifiche al codice:

git log -p

1 4 9

2 3

5 8 10

60

Cambio di versione(Si usa il comando git checkout)

È possibile esplorare le diverse versioni corrispondenti a branch ed etichette con il comando git checkout.Ad esempio, per ottenere la versione corrispondente al tag “v2.10”:git checkout v2.10

È possibile ritornare in ogni istante al branch master digitando:git checkout master

61

Analisi delle differenze fra versioni(Si usa il comando git diff)

Il comando git diff elenca tutte le differenze fra due specifiche porzioni di progetto (commit, tag).Ad esempio, per trovare le differenze fra la versione v2.8 e la versione v2.9 di GNU Hello:

git diff v2.8 v2.9Per trovare le differenze fra l'ultimo commit (HEAD) ed il penultimo (HEAD^):

git diff HEAD^ HEAD

62

Esercizio 6 (2 min.)Visualizzate le differenze fra l'ultima e la penultima versione delle coreutils.

63

Aggiornamento di un repository GIT(Si usa il comando git pull)

Periodicamente è opportuno aggiornare il repository allo stato più recente. Si usa il comando seguente:

git pull

64

INDICIZZAZIONE DEL CODICE SORGENTE

65

Scenario e interrogativi(Come si scarica un archivio sorgente?)

Scenario: dopo aver scaricato il software, lo studente vuole studiarlo. Si tenga presente che l’albero sorgente dei software coinvolti è gigantesco, ed una semplice lettura di singoli file non è sufficiente.

Interrogativi:Come si analizza il codice sorgente di un software complesso?

66

Indicizzazione del codice(Ovvero come navigare e orientarsi in mezzo all'oceano)

L'indicizzazione del codice è un insieme di meccanismi che consente di associare etichette navigabili a simboli (funzioni, variabili, file).Esistono molteplici meccanismi:

siti Web contenenti gli alberi di codice già indicizzati;comandi UNIX per l'indicizzazione di alberi sorgente(integrabili con i principali editor).

67

Indicizzatori Web-based(Forse questi sono più adatti per iniziare)

Alcuni indicizzatori sono presenti sotto forma di servizi Web. Ad esempio, per il kernel è disponibile il sito:

https://lxr.free-electrons.com/

Si dovrebbe vedere l'albero sorgente del kernel, navigabile tramite hyperlink.È anche possibile cliccare sulla versione del kernel su cui operare.

https://lxr.free-electrons.com/

68

Quale è la versione del kernel?(Prima di cliccare sulla versione, bisogna individuarla)

Il comando uname stampa informazioni sul kernel.Si digiti il comando seguente: uname -a.La versione del kernel in Debian è la 4.19.0-12-amd64.4: numero di versione principale del kernel (aumenta ad ogni cambiamento epocale).19: numero di versione secondario del kernel rilasciato da Linus Torvalds (aumenta ogni tre mesi con il rilascio di una nuova versione).0: rilasci “bugfix” effettuati dallo stable team del kernel.12: rilasci “bugfix” effettuati dal kernel team di Debian.

69

Scelta di una versione “vicina”(Nell'indicizzatore Web-based)

L'indicizzatore fornisce la versione 4.19 del kernel (la linea di sviluppo principale rilasciata da Linus Torvalds in persona), non la versione 4.19.0 (gestita dallo Stable Team).

→ Si clicca su “4.19”, tenendo ben presente che possono esistere differenze rispetto alle versioni fornite da Debian.

Driver di dispositivo, in primis.Lo zoccolo duro del kernel non dovrebbe cambiare.

70

Ricerca di simboli(Con la versione del kernel corretta)

Cliccando su “Identifier Search” è possibile effettuare una ricerca dei simboli (funzioni, variabili). Si cerchi, ad esempio, il simbolo start_kernel.Si selezioni il risultato “init/main.c, line 531”.Secondo voi, che cosa fa tale funzione?

71

Navigazione dei simboli(È possibile cliccare sulle strutture dati e sulle funzioni)

Cliccando su una qualunque invocazione di funzione o struttura dati è possibile risalire immediatamente alla relativa definizione.Ad esempio, nella funzione start_kernel() si può investigare cosa succede nella funzione rest_init() (l'ultima invocata), cliccandoci sopra.Una volta in rest_init(), si potrebbe provare a studiare la funzione kernel_init(), cliccando sul simbolo kernel_init alla riga 368.

72

start_kernel()(Inizializza le periferiche e fa partire /sbin/init. Cos'altro potrebbe fare?)

Inizializza le risorse hardware.Inizializza le strutture dati del kernel.Crea a mano un processo e carica l’immagine di /sbin/init.Schedula il processo /sbin/init per l'esecuzione.Init avvia le restanti applicazioni.

73

Esercizio 7 (2 min.)Usando l'indicizzatore Web-based del kernel, si trovi il simbolo:

init_uts_nsSecondo voi, di che cosa è responsabile tale simbolo?

74

Indicizzatori da linea di comando(They save the day when Web-based indexers are not available)

Gli indicizzatori Web-based, in quanto servizi remoti, possono non essere sempre disponibili.

È il caso di http://lxr.linux.no, storico indicizzatore delkernel, messo offline nel 2014.

Legge di Murphy: gli indicizzatori Web-based non funzioneranno nell'esatto momento in cui vi servono maggiormente.

Soluzione arzigogolo, progetto per un esame, lavoroconsulenziale, scrittura di un nuovo device driver…

Serve un'alternativa sempre disponibile: un indicizzatore che operi da linea di comando.

http://lxr.linux.no/

75

Un indicizzatore stile UNIX(http://cscope.sourceforge.net/history.html)

Il programma cscope permette di ricercare agevolmente funzioni, simboli e nomi di file all'interno di progetti grandi.Funzionalità offerte:

menu di navigazione per file, regexp, simboli.integrazione con l'editor vim.

Si proverà ad indicizzare l'albero sorgente delle coreutils con cscope.

76

In che linguaggio è scritto il progetto?(C? C++? Assembly? Script? Misto?)

Cscope richiede un file contenente l'elenco di tutti i file sorgenti del progetto. I file sono scanditi alla ricerca di simboli (variabili, funzioni, …).Cscope non può sapere in che linguaggio è scritto il progetto e, di conseguenza, non sa in anticipo quali file contengono codice.Si dà un'occhiata iniziale all'albero sorgente:

ls -lR.Si controlla il compilatore usato dal Makefile.Nel caso di coreutils, si tratta di un progetto in C.

77

Quali file contiene il progetto?(Un uso raffinato di find)

Cscope si aspetta nella root dell'albero un file dal nome cscope.files contenente l'elenco dei percorsi dei file contenenti codice.Progetto in C file con estensione → .c, .h.Come si trovano tutti i file con tali estensioni?

find . -regex '.*\.[ch]' > cscope.filesCerca i file con una

espressione regolare

Sequenzaarbitraria di

caratteriCarattere

puntoCarattere

c o h

78

Indicizzazione(A cura di cscope)

L'indicizzazione vera e propria, da fare la prima volta che si esegue cscope, è semplice.

cscope -bL'opzione -b costruisce l'indice dei simboli e lo memorizza nel file cscope.out.

79

Uso(Finalmente!)

Basta scrivere cscope e si entra nel menu principale.Si possono usare i tasti cursore Su/Giù per scegliere il tipo di ricerca. I tipi di ricerca disponibili sono i seguenti.

Simbolo (definizione ed usi).Definizione globale.Funzioni invocate.Funzioni invocanti.Testo.Espressioni regolari.Nomi di file.

80

Un esempio(Non è semplicissimo)

Il pacchetto coreutils contiene le utility da linea di comando di un sistema base GNU/Linux. Ci si aspetta di trovare tante funzioni main(), una per ogni eseguibile fornito dal pacchetto.Si scelga la funzione “Find this C symbol” , si digiti main e si prema il tasto INVIO.

81

Navigazione dei risultati(Visto? Non è esattamente semplicissimo)

Tasti 0-8: scelta dei primi 9 risultati trovatiIn alternativa: Cursore Su/Giù + INVIO.

Una volta scelto il risultato, si apre l'editor VIM alla riga relativa.

Si legge il codice, lo si modifica, si esce con :q.Per chi pensa che VIM sia un detersivo in polvere:http://www.openvim.com/tutorial.html

82

Esercizio 8 (5 min.)Trovate la definizione della funzione do_copy() e capite a che cosa serve. Suggerimento: in che file si trova?Quali funzioni invoca la do_copy()?Quali funzioni invocano la do_copy()?

Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Slide 26Slide 27Slide 28Slide 29Slide 30Slide 31Slide 32Slide 33Slide 34Slide 35Slide 36Slide 37Slide 38Slide 39Slide 40Slide 41Slide 42Slide 43Slide 44Slide 45Slide 46Slide 47Slide 48Slide 49Slide 50Slide 51Slide 52Slide 53Slide 54Slide 55Slide 56Slide 57Slide 58Slide 59Slide 60Slide 61Slide 62Slide 63Slide 64Slide 65Slide 66Slide 67Slide 68Slide 69Slide 70Slide 71Slide 72Slide 73Slide 74Slide 75Slide 76Slide 77Slide 78Slide 79Slide 80Slide 81Slide 82