• Regolamento Macrocategoria DEV
    Prima di aprire un topic nella Macrocategoria DEV, è bene leggerne il suo regolamento. Sei un'azienda o un hosting/provider? Qui sono anche contenute informazioni per collaborare con Sciax2 ed ottenere l'accredito nella nostra community!

Info Il kernel e le chiamate di sistema

System32

Utente Stellare
Autore del topic
2 Gennaio 2010
15.556
112
Miglior risposta
0
Buonasera fanciulli, poco fa sono tornato dalla palestra e sono distrutto al 200% per cui mi rilasso scrivendo questa "informazione" che risulta essere molto utile per capire molte cose; via via leggendo capirete a quali "cose" mi riferisco. Dunque, l'argomento di oggi sono le cosiddette chiamate di sistema, e scrivo questo topic nella sezione C/C++ perché questi due linguaggi sono l'ideale per parlare di questo argomento. Le chiamate di sistema, o comunemente chiamate col termine inglese system call sono delle funzioni che i programmi "chiamano", ovvero che vogliono eseguire, per determinati scopi. Prima di capirle meglio però è bene capire prima cos'è una funzione. Una funzione, o anche comunemente detta "metodo", è una successione di istruzioni che interpreta la macchina per svolgere diversi compiti. Le funzioni sono la base della programmazione, sia procedurale che ad oggetti, e pertanto sono fondamentali per scrivere i programmi perché scrivere buone funzioni equivale a scrivere un buon programma, sia a livello del codice che a livello della logica del programma. Adesso parliamo delle chiamate di sistema. Le chiamate di sistema come detto prima sono delle funzioni che, tra virgolette, sono "conosciute" dalla macchina perché sono set di istruzioni che la macchina riesce ad interpretare, quindi ad eseguire. La cosa più interessante però è comprendere come queste chiamate di sistema sono possibili, perché non sempre lo sono da parte dei programmi, in un computer. Ebbene dovete sapere che in un sistema operativo multiprogrammato, come quelli da qualche anno a questa parte, l'utente ha una determinata "possibilità" di utilizzo del computer. Questa possibilità non è altro che quella di poter mandare in esecuzione i programmi quindi è facile comprendere che le chiamate di sistema non dipendono dall'utente ma dal programma che egli decide di eseguire, ma questo lo avevo già scritto. Quindi i programmi che l'utente manderà in esecuzione, essendo un set di istruzioni che la macchina è in grado di eseguire, potrà permettersi, salvo diversi limiti, di effettuare le chiamate di sistema. In realtà sto parlando di "chiamate di sistema" ma non vi sto dicendo niente, solo "cenni" per capire quello che andrò più in là a scrivere. Parlando di ambienti GNU/Linux, così come in ambiente Windows, non tutti gli utenti possono permettersi di lanciare dei programmi che chiamano delle funzioni del sistema poiché ogni utente ha un privilegio diverso, dettato dall'uid ( user-id ), quindi, come spero sappiate, l'unico utente in grado di poter mandare in esecuzione qualsiasi programma è il superutente, o comunemente conosciuto come root, l'amministratore, in parole povere. Questo perché si pensa che l'amministratore sia in grado di gestire perfettamente i sistemi GNU/Linux, non facendo quindi qualcosa che potrebbe portare ad un improvviso non funzionamento del sistema. Come lavorano le chiamate di sistema ? Per spiegarvelo vi farò un esempio "disegnato immaginariamente" quindi supponiamo di avere un programma, lanciato dall'utente, che vuole chiamare GetAsyncKeyState() ( vi rimando alla documentazione in caso qualcuno non sappia cosa fa questa funzione ->
Perfavore, Entra oppure Registrati per vedere i Link!
). Ora voi potrete immaginare che il programma dica al computer "ehy amico, devo eseguire questa funzione, permettimi di farlo". A tal punto il computer ti dirà "vedi che non devi essere tu ad eseguire la funzione...devi passare il controllo al mio amico kernel, poi ripasserà il controllo a te con tutto quello che ti serve". Stiamo quindi introducendo il kernel....che come potrete leggere su Wikipedia viene descritto come il nucleo del sistema operativo; vi siete mai chiesti il perché ? Sì ok, "nucleo" in questo caso vuol dire che è "la base del sistema operativo" o comunque qualcosa di importante, ma questo "nucleo" che compito ha ? Scommetto che non ve lo siete mai chiesto, ebbene il compito del kernel è quello di mettersi in mezzo al programma e all'hardware. Vi spiego meglio : riprendendo l'esempio della funzione GetAsyncKeyState, il programma passerà il controllo al kernel il quale si occuperà di dialogare con l'hardware, la tastiera, nel caso di questa funzione, e in base all'operazione che vuole eseguire il programma il kernel, controllando prima ancora di dialogare con l'hardware se il programma può chiamare quella funzione, restituirà i risultati dell'operazione richiesta dal programma. Sembra una cosa macchinosa da comprendere ma non lo è affatto, è semplice. La cosa fondamentale da capire, e qui concludo, è che non è possibile lavorare direttamente con il kernel, nel senso : non è possibile che le chiamate di sistema non vengano gestite dal kernel perché quando un programma è in esecuzione e chiama una determinata funzione il kernel è sempre pronto ad interrompere l'esecuzione del programma, lavorare con l'hardware, e restituire al programma quello che gli interessa; per questo quando programmiamo in C il compilatore ci fornisce l'errore di impossibilità di eseguire una funzione. Questo o perché la funzione non esiste oppure perché il programma non può eseguirla a causa dell'utente che non dispone dei privilegi giusti per eseguire quella funzione; difatti il messaggio di errore lo visualizziamo perché il kernel, successivamente al dialogo con l'hardware, lancia a sua volta un altro programma, il linker, che si occupa di "linkare" ovvero di "collegare" le funzioni degli header con quelle che chiamiamo noi ( controllando i parametri delle funzioni ) e che sua volta manda il messaggio di errore al kernel, il kernel lo manda al programma e così l'utente può infine visualizzarlo.

Spero che la spiegazione sia stata chiara, se così non fosse ponete domande.
Alla prossima.