[Linux] le syscall

[misterx]

sinceramente non sapevo dove postare una domanda del genere, in scienza e tecnica non mi sembrava troppo appropriata in quanto poi se si tira in ballo il codice dopo aver discusso a livello concettuale mi sembrava fuori luogo, spero di aver azzeccato il luogo.

Non conoscendo la filosofia di Linux ma sapendo che pure questo SO ha le sue syscall, mi chidevo come funzionano.

Premetto che sto studiando minix e per quanto concerne le chiamate di sistema almeno l'approcio iniziale dovrebbe essere il medesimo.

Il sistema minix consta di un certo numero di livelli partendo dal più basso abbiamo: il kernel il clock task ed il system task.
Salendo i livelli troviamo i diver, i server ed infine i processi utente.

Bene, dopo questa premessa mi chiedo: quando un programma a livello utente chiama un servizio tipico del kernel, chiede al livello inferiore un servizio e poi questo al suo livello inferiore sino ad arrivare al kernel ?

Questo modo di comportarsi mi ricorda molto il modello ISO/OSI relativo alle reti.

[cdimauro]

Sì, il concetto è quello: si sale (o scende, a seconda dei punti di vista ) finché il componente di un certo strato non è in grado di soddisfare la richiesta dell'applicazione.

Nei sistemi dotati di microkernel e in cui vengono utilizzate primitive di comunicazione di tipo messagge passing o similiari, è possibile che ci siano dei buffer che "raccolgono" batch di richieste, in modo da spedirne un blocco al livello superiore e minimizzare, ove possibile, l'overhead dovuto a tale passaggio (esempio: passare da user-mode a kernel-mode è costoso per una CPU, per quanto possa essere agevolata da apposite API).

[misterx]

ah grazie.
Stavo meditando ancora sui livelli

Quindi ad esempio, se un processo utente chiama la fork() che risulta essere una system call senza parametri, questa viene rediretta tramite passaggi verso il kernel che duplicherà il processo chiamante(il padre).

Mi viene da pensare che se il processo passasse direttamente la fork() così com'è direttamente al kernel, forse il kernel non avrebbe i riferimenti per capire chi deve duplicare allora, questa benedetta fork() scendendo i vari livelli, viene trasformata da opportune funzioni presenti in determinate librerie e che fungono da interfaccia verso il kerne, e la trasformazione consiste nell'aggiungere ulteriori informazioni per il kernel come credo ad esempio: il PID, il messaggio che rappresenta la fork() etc...

Ma funziona così ?

[cdimauro]

Originariamente inviato da misterx

ah grazie.
Stavo meditando ancora sui livelli

Quindi ad esempio, se un processo utente chiama la fork() che risulta essere una system call senza parametri, questa viene rediretta tramite passaggi verso il kernel che duplicherà il processo chiamante(il padre).

Sì.

Mi viene da pensare che se il processo passasse direttamente la fork() così com'è direttamente al kernel, forse il kernel non avrebbe i riferimenti per capire chi deve duplicare allora, questa benedetta fork() scendendo i vari livelli, viene trasformata da opportune funzioni presenti in determinate librerie e che fungono da interfaccia verso il kerne, e la trasformazione consiste nell'aggiungere ulteriori informazioni per il kernel come credo ad esempio: il PID, il messaggio che rappresenta la fork() etc...

Ma funziona così ?

Non esattamente. Il kernel conosce già in partenza il PID del processo, per cui non ha bisogno che quest'informazione venga "aggiunta" nei vari passaggi di livello.

Per la fork() penso che il PID sia l'unica informazione di cui ha bisogno per duplicare il processo, perché questo numero individua una struttura in kernel space in cui sono conservati tutti i dati necessari per capire quali risorse utilizza un processo e, quindi, in che modo poterle duplicare (se serve) per crearne un clone.

[misterx]

Grazie ancora.

Nel caso della fork() quindi, i vari livelli servono per tenere lontani i software di livello user dal PID ad esempio ?

In questo modo, grazie ai livelli, nascondi la complessità ai livelli superiori almeno, questa è l'utilità pratica che ho colto io dei livelli. Con i livelli io sotto, a livello kernel, posso fare quello che voglio e il tuo programma, ma anche tutte le migliaia di programmi già scritti e compilati che ci sono in giro, richiamando semplicemente la fork() non devono essere necessariamente ricompilati e continueranno a funzionare.
Al contrario, se chiamavi direttamente la sys_call come fa il kernel, magari dovendo specificare diversi parametri, se a livello kernel ne aggiungo o tolgo uno di detti parametri obbligherei tutti a ricompilare.

Chissà se ho colto!

[cdimauro]

Originariamente inviato da misterx

Grazie ancora.

Nel caso della fork() quindi, i vari livelli servono per tenere lontani i software di livello user dal PID ad esempio ?

No, il PID e altre informazioni possono tranquillamente essere noti a tutti i livelli. Dipende tutto dal "grado" di astrazione che vogliamo imprimere al nostro s.o..

In questo modo, grazie ai livelli, nascondi la complessità ai livelli superiori almeno, questa è l'utilità pratica che ho colto io dei livelli. Con i livelli io sotto, a livello kernel, posso fare quello che voglio e il tuo programma, ma anche tutte le migliaia di programmi già scritti e compilati che ci sono in giro, richiamando semplicemente la fork() non devono essere necessariamente ricompilati e continueranno a funzionare.
Al contrario, se chiamavi direttamente la sys_call come fa il kernel, magari dovendo specificare diversi parametri, se a livello kernel ne aggiungo o tolgo uno di detti parametri obbligherei tutti a ricompilare.

Chissà se ho colto!

Chiaro, e infatti si astrae sia per due motivi: nascondere dettagli (man mano che si sale di livello di astrazione) e si "pone una barriera", un filtro, una porta che dir si voglia, che regoli il passaggio da un livello a un altro.

A tal proposito alla recente PyCon3 c'è stato un talk di Alex Martelli sull'argomento che è stato illuminante. Ti consiglio di leggerlo perché ne vale veramente la pena (e, meglio ancora, guardarti il video quando sarà disponibile, fra qualche mese).

[misterx]

domanda apparentemente banale
Sto implementando una nuova syscall in minix e siccome è la prima volta che sbircio all'interno di un SO, il fatto che minix come del resto altri SO sia costruito a livelli significa che:
- scrivo il programma A che necessita del programma sottostante B e che a sua volta necessita del livello sottostante C etc....

Così dicendo è quindi una scelta implementativa e cioè, nessuno mi vieta di by-passare tutti i livelli sottostanti e parlare direttamente col kernel sempre che si sappia dove mettere le mani.

Perchè sto discorso ?
Perchè solo passando dallo studio concettuale alla pratica ci si accorge che i livelli non sono altro che concetti nel senso che, nessuno mi vieta di implementare la mia funzione direttamente nel kernel e far parlare una applicazione di livello user direttamente co livello kernel, giusto ?

Ovviamente così facendo manderei a ramengo tutta la filosofia sulla quale si erge l'idea minix!

In definitiva le istruzioni che si possono trovare in giro circa l'implementazione di una nuova syscall in minix non sono altro che le volontà di Tanenbaum e cioè: se vuoi che minix continui a funzionare nel modo da me stabilito devi:
- dichiarare nella directory xyz la tua nuova syscall
- implementare la tal funzione nella directory abcd
- ricompilare e richiamare la syscall

Questo significa sposare la filosofia di un SO ?

Scusate la lungaggine ma grazie infinite a chi mi leggerà

[cdimauro]

Sostanzialmente sì, e proprio per questo NON aggiungerei API al microkernel: proprio perché è "micro", sarebbe meglio aggiungerle negli strati software che girano in user mode.

[misterx]

grazie per la risposta

Ti risulta che quando compili il kernel questo ha già indirizzi fissi in memoria dove piazzarci le varie tabelle per le varie gestioni degli interrupt ad esempio e le eccezioni ?

[misterx]

accumulo un'altra domanda

push eax
mov eax, 0+4(esp)
mov (old_eip), eax
mov eax, 4+4(esp)
mov (old_cs), eax
mov eax, 8+4(esp)
mov (old_eflags), eax

come mai non viene memorizzato il contenuto dello stack direttamente nelle variabili ma si passa prima dal registro eax ?

Cioè anzichè:

mov eax, 0+4(esp)
mov (old_eip), eax

non si scrive:

mov (old_eip), 0+4(esp)

[cdimauro]

Originariamente inviato da misterx

grazie per la risposta

Ti risulta che quando compili il kernel questo ha già indirizzi fissi in memoria dove piazzarci le varie tabelle per le varie gestioni degli interrupt ad esempio e le eccezioni ?

Alcuni kernel possono memorizzare delle strutture a indirizzi fissi, ma in questo modo si legano all'architettura.

In generale è sempre meglio non fare assunzioni su dove mettere certe strutture, anche perché le architetture moderne permettono di rilocare praticamente qualunque dato.

Originariamente inviato da misterx

accumulo un'altra domanda

push eax
mov eax, 0+4(esp)
mov (old_eip), eax
mov eax, 4+4(esp)
mov (old_cs), eax
mov eax, 8+4(esp)
mov (old_eflags), eax

come mai non viene memorizzato il contenuto dello stack direttamente nelle variabili ma si passa prima dal registro eax ?

Cioè anzichè:

mov eax, 0+4(esp)
mov (old_eip), eax

non si scrive:

mov (old_eip), 0+4(esp)

Perché non hai un Motorola 68000, ma un ben più semplice 80386.

[misterx]

Originariamente inviato da cdimauro

Perché non hai un Motorola 68000, ma un ben più semplice 80386.

che significa ?

[cdimauro]

Significa che un 68000+ è in grado di eseguire una copia fra due locazioni di memoria con una sola istruzione MOVE, mentre un 386+ no, perché la sua MOV può avere soltanto un indirizzo di memoria per i suoi due operandi, e l'altro deve necessariamente essere un registro.

[misterx]

Originariamente inviato da cdimauro

Significa che un 68000+ è in grado di eseguire una copia fra due locazioni di memoria con una sola istruzione MOVE, mentre un 386+ no, perché la sua MOV può avere soltanto un indirizzo di memoria per i suoi due operandi, e l'altro deve necessariamente essere un registro.

ah, grazie

[tomminno]

Originariamente inviato da cdimauro

Significa che un 68000+ è in grado di eseguire una copia fra due locazioni di memoria con una sola istruzione MOVE, mentre un 386+ no, perché la sua MOV può avere soltanto un indirizzo di memoria per i suoi due operandi, e l'altro deve necessariamente essere un registro.

Sbaglio o le istruzioni memoria-memoria sono da considerarsi come la peste?
E sono istruzioni che un'architettura RISC non supporterà mai?

[cdimauro]

Originariamente inviato da tomminno

Sbaglio o le istruzioni memoria-memoria sono da considerarsi come la peste?

Dipende dall'architettura: sui CISC sono, invece, quelle più ambite.

E sono istruzioni che un'architettura RISC non supporterà mai?

I RISC non supportano nemmeno le istruzioni memoria<->registro (le uniche consentite sono le LOAD e le STORE): figuriamoci quelle memoria<->memoria.

[fero86]

Originariamente inviato da tomminno

Sbaglio o le istruzioni memoria-memoria sono da considerarsi come la peste?

motivare é fatica vedo.

[cdimauro]

Non essere così duro: potrebbe essere un legittimo dubbio. Non si nasce esperti di architetture degli elaboratori...

[tomminno]

Originariamente inviato da fero86

motivare é fatica vedo.

La domanda era retorica.
x86 rimane pur sempre un'architettura CISC, che avrebbe anche consetito l'inserimento di tale (architetturalmente parlando) bestialità.
In questo caso x86 batte il 68000 ma dopotutto uno è vivo e vegeto l'altro è morto.

[cdimauro]

Originariamente inviato da tomminno

La domanda era retorica.
x86 rimane pur sempre un'architettura CISC, che avrebbe anche consetito l'inserimento di tale (architetturalmente parlando) bestialità.

Io la considero una funzionalità eccellente, non una bestialità: http://www.appuntidigitali.it/3838/m...ione-a-32-bit/

E parlo da programmatore assembly 680x0 e 80x86 di lunga data.

A questo punto, visto che non sei a digiuno sulle architetture degli elaboratori, una spiegazione del perché sarebbe una bestialità non sarebbe male.

In questo caso x86 batte il 68000

In semplicità dell'ISA da una parte (perché implementare un decoder che consente di specificare una qualunque modalità di indirizzamento per entrambi gli operandi è più complicato), ma ha un design pessimo dall'altra, con una tabella degli opcode organizzata in maniera pseudocasuale e l'uso dei prefissi che complica ulteriormente la decodifica delle istruzioni.

ma dopotutto uno è vivo e vegeto l'altro è morto.

Il che non vuol dire proprio nulla.