Rivisti i capitoli 1 e 2

La revisione dei primi due capitoli della guida è stata completata. In particolare il secondo capitolo ha visto una serie di risistemazioni con l’accorpamento e la ristrutturazione di alcune sezioni. Si è spiegata con maggior dettaglio la differenza fra system call e chiamate a funzioni ed il ruolo del link-loader ed il significato di variabili automatiche, globali, statiche ecc.

Si è migliorata la sezione sulla allocazione della memoria con delle correzioni ad alcune imprecisioni ed una più chiara esposizione del layout della memoria di un processo, si sono aggiornate le sezioni sulle funzioni variadic e le variabili di ambiente. La sezione sulla localizzazione resta incompleta.

Inizio revisione

Approfittando delle ferie natalizie ho iniziato la revisione della Guida per renderla stampabile in formato Crown Quarti (quello dei testi della OReilly, tanto per fare un esempio) e cercare di migliorare anche alcune formattazioni (in particolare quelle dei riquadri delle funzioni) e sistemare una serie di macro Latex.

Per questo motivo fin tanto che la revisione sarà in corso si potranno avere errori di compilazione e una formattazione incoerente dei contenuti utilizzando la versione scaricabile da SVN.

Upload nuovo PDF

Dato che il PDF pubblicato (nella pagina dei download) era parecchio vecchio ho provveduto ad una sua ripubblicazione. Ho aggiornato anche la versione stampabile su Lulu.com, ed il relativo PDF. Questa sarà probabilmente l’ultima versione in volume unico essendo ormai raggiunto il limite delle 750 pagine oltre il quale non è possibile più stampare un testo.

Completate le sezioni su “capabilities” e ”prctl”

La sezione sulle capabilities è stata completamente rivista, con tutti gli aggiornamenti alla situazione realizzata con l’introduzione del supporto completo delle stesse a partire dal kernel 2.6.26.

Al contempo è stata introdotta una nuova sezione sulla system call prtcl, e ristrutturata la parte finale del capitolo sui processi, introducendo una sezione, ancora completamente da scrivere, su clone.

In memoria

Poco tempo fa è morta una delle persone più significative nella storia dell’informatica, un uomo che ha lasciato un segno indelebile nello sviluppo di questa disciplina.

No, non si tratta di Steve Jobs.

Dennis Ritchie non era un imprenditore di successo che riusciava a vendere a proseliti adoranti macchine chiuse e costose usabili solo come gadget tecnologici secondo quanto imposto dalla sua azienda.

Dennis Ritchie era un ricercatore, una persona che l’informatica l’ha creata, dando un contributo il cui rilievo non sta nella apparenza, ma nella sostanza.

Dennis Ritchie non era neanche un informatico, era un fisico che si appassionò alla nuova scienza ed andò a lavorare ai laboratori della AT&T.

Lì con Brian Kernigan dette vita al C, il linguaggio con cui sono scritti tutti i sistemi operativi (almeno tutti quelli di uso pratico).

Lì con Ken Thompson creò Unix, un sistema operativo la cui architettura, nonostante i decenni passati, resta totalmente attuale ed è alla base, oltre che di Linux, anche del sistema usato dal venditore di successo.

Uno solo di questi risultati sarebbe stato sufficiente ad entrare nella storia dell’informatica, una persona capace di essere alla base di due delle più grandi innovazioni di questa disciplina non può che meritare un tributo eccezionale.

Ma non aspettatevi di trovarlo nei dibattiti in televisione, al più finirà in qualche trafiletto secondario sui giornali. L’apparenza oggi purtroppo conta molto di della sostanza, ed il successo di misura in fatturato, non in invenzioni.

Se si deve ricordare una persona che ha davvero creato qualcosa di significativo e importante nell’informatica, difficilmente qualcuno potrà superarlo.

Riporto qui per quanto girato sulla rete in sua memoria:

Dennis Ritchies logged-off
His pointer has been cast to void *
His process has terminated with exit code 0

Trattazione delle quote disco

Al capitolo sulla gestione di file e directory è stata aggiunta una nuova sezione dedicata alla trattazione delle funzioni (in realtà è una sola, quotactl) per la gestione delle quote disco. Oltre alle spiegazioni sono stati aggiunti alcuni esempi di un modulo Python (scritto in C) che consente di effettuare le operazioni sulle quote disco chiamando direttamente la suddetta funzione.

Per l’occasione il modulo è stato esteso anche con la gestione dell’impostazione dei grace time, e pubblicato insieme ai sorgenti dei pacchetti Debian di Truelite, pertanto si potrà ottenerne il codice completo a partire dalla relativa pagina, raggiungibile all’indirizzo:

http://labs.truelite.it/projects/packages/wiki/QuotaModule

Revisione del capitolo su terminali e sessioni

Ho completato una breve revisione del capitolo 10, originariamente intitolato “Terminali e sessioni di lavoro“. Il nuovo titolo, che tiene conto del fatto che vi si parla anche di demoni e del syslog, è diventato “Interfaccia utente: terminali e sessioni di lavoro“.

Sono stati aggiornate e riviste alcune parti introduttive, sottolineando il significato della console di sistema, e riscritta in buona parte la sezione su demoni e syslog, aggiungendo alcune funzioni di libreria (vsyslog, closelog) che non erano state trattate e aggiungendo la trattazione della gestione dei log del kernel (klogctl) prima totalmente assente.

Per fare alcuni test relativi all’uso di klogctl si è inoltre scritto un piccolo programma di test (mydmesg.c) che ha anche rivelato che una delle operazioni di klogctl non si comporta esattamente come descritto nella pagina di manuale.

Infine sono state riviste anche le parti relative alla gestione dei terminali, aggiornando i flags di termios, e le varie funzioni associate alla manipolazione delle caratteristiche dei terminali, aggiungendo alcune funzioni non trattate precedentemente (cfmakeraw, cfsetspeed). Resta ancora da fare la parte sulla gestione dei terminali virtuali.

Alcuni dettagli di timerfd.

A partire dal kernel 2.6.25 è stata introdotta una interfaccia di gestione alternativa per i timer di sistema che consente la ricezione delle notifiche di scadenza attraverso dei file descriptor invece che tramite segnali o thread, chiamata convenzionalmente timerfd.

L’interfaccia è specifica di Linux e si unisce ad altre due (signalfd e eventfd) che seguono la stessa filosofia per la ricezione di segnali e di eventi dal kernel. Il grande vantaggio è che queste possono essere usate in combinazione con le funzioni dell’I/O multiplexing (poll, select ed epoll) semplificando notevolmente la gestione l’attesa contemporanea di eventi e dati.

L’interfaccia timerfd segue da vicino quella introdotta da POSIX.1-2001 che è trattata nella sezione 9.5.2 della guida, che però fa ricorso a meccanismi di notifica classici. Nel trattare la nuova interfaccia mi è sorto un dubbio relativo al funzionamento della stessa quando si esegue una fork.

Con i timer ordinari infatti un processo figlio non eredita dopo una fork nessuno dei timer del padre. La semantica Unix prevede però che un file descriptor sia duplicato attraverso una fork, e dato che in questo caso un timer viene associato ad un file descriptor la domanda su cosa accada al timer nel processo figlio sorge spontanea.

La documentazione dice che il file descriptor associato ad un timer continua a seguire la semantica ordinaria e viene duplicato nel figlio. Viene cioè preferita la semantica dei file descriptor rispetto a quella dei timer ordinari. Sorge però spontanea la domanda di cosa succede se padre e figlio iniziano a leggere entrambi da tale file descriptor per ricevere la notifica delle scadenze dei timer.

La documentazione delle pagine di manuale, almeno nella versione della mia Debian, non dice nulla, ma “a naso” ci si aspetterebbe che accada la stessa cosa che accade per un file descriptor duplicato, e cioè che chi legge per primo riceve i dati, lasciando “a bocca asciutta” l’altro processo.

Per verificarlo ho comunque scritto un programma di test, test_timerfdfork.c, che arma un timer con timerfd esegue una fork ed usa epoll per l’attesa in entrambi i processi. Il programma prevede delle opzioni per specificare i valori della struttura itimerspec che impostano prima scadenza e ripetizione del timer.

Se lo eseguiamo mettendo un tempo di prima scadenza a due secondi, ed un tempo di ripetizione ad un secondo, otterremo qualcosa del tipo:

piccardi@hain:~/gapil/sources$ gcc test_timerfdfork.c
piccardi@hain:~/gapil/sources$ ./a.out -i1 -t2
Timer interval 2 sec, timer time 1 sec
Got 1 events, pid 12513, time 1308661930
Timer expired in pid 12513:
Expired 1 times in pid 12513
Got 1 events, pid 0, time 1308661930
Timer expired in pid 0:
Got 1 events, pid 0, time 1308661931
Timer expired in pid 0:
Expired 1 times in pid 0
Got 1 events, pid 0, time 1308661932
Timer expired in pid 0:
Expired 1 times in pid 0
Got 1 events, pid 0, time 1308661933
Timer expired in pid 0:
Expired 1 times in pid 0

e come ci si aspettava viene letta una scadenza alla volta, nel caso la prima volta nel figlio e le successive nel padre (ma la cosa è casuale e rilanciandolo di possono ottenere diversi risultati), cosa che corrisponde al fatto che il primo processo che esegue una lettura sul file descriptor riceve il dato della scadenza.

Un programma di esempio per sa_sigaction

Nella caccia ad un bug che faceva sì che i CGI bloccati non venissero correttamente terminati da Apache nonostante la direttiva Timeout fosse impostata correttamente, ho scritto un semplicissimo CGI che non facesse niente, allo scopo di capire di cosa stesse succedendo.

Alla fine il problema, almeno su Debian Lenny, era che sulle macchine a 64 bit (e solo su quelle) mod_deflate manda in SEGFAULT il sottoprocesso di Apache che a sua volta lancia il CGI se questo non ha generato nessuna uscita, con il risultato che poi il segnale di terminazione (che per i curiosi che come me lo han cercato invano nella documentazione, è SIGTERM) non viene inviato ed il CGI resta in esecuzione, orfano, per l’eternità.

Ma prima di arrivare alla conclusione che il segnale non veniva neanche lanciato, per capire da chi e come arrivasse in condizioni normali (e per essere sicuri che non ci fossero problemi di intercettazione) ho scritto questo piccolo programma, che si limita ad attendere indefinitamente, e scrive su un file (dall’interno del gestore) quello che vede.

Per farlo ho usato versione avanzata dei gestori di segnali (quelli impostati con un campo sa_sigaction) che prevedono anche il ritorno in un argomento siginfo_t di una serie di dati relativi al segnale, come il PID del processo che lo ha inviato. Il programma è molto semplice e appena avrò un po’ di tempo lo inserirò come esempio nel testo per questa funzionalità, per chi fosse curioso si trova a questo indirizzo:

http://gapil.truelite.it/sources/browser/trunk/sources/testsignalcgi.c

Codifica caratteri

In questa settimana ho convertito tutti i sorgenti di GaPiL a UTF8, questo questo però comporterà che la visualizzazione con Trac del codice Latex delle differenze introdotte  conversione non sarà del tutto corretta. Chiunque riscontri altri problemi di visualizzazione è pregato di segnalarlo.

Tags: ,
This work by Simone Piccardi is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported.