[Linux] le syscall

[cdimauro]

Up.

[misterx]

mi ci è voluto un pochino a mettermi nei panni del kernel, ragionavo sempre da sviluppatore di applicazioni
Difatti quando un processo faceva una send, mi domandavo come potesse scrivere nelle strutture dell'altro pocesso poi mi sono detto: alt! è il kernel che gioca con i due processi e allora tutto è diventato leggermente più chiaro: minix non è poi così brutto come lo si vuole dipingere

[tomminno]

Originariamente inviato da cdimauro

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

Semplicemente motivi di efficienza e semplicità architetturale tanto cari alla filosofia RISC.
Operazioni memoria memoria comportano un supporto da parte di entrambi gli operandi di tutte le possibili combinazioni di indirizzamento, ovvero tanti opcode da gestire.
La cosa è evidenziata anche nell'articolo da te citato:

Purtroppo questo è stato anche il suo tallone d’Achille, perché a una grande facilità di fruttamento da parte dei programmatori s’è contrapposta un’architettura interna molto “pesante” e “complicata”

Poi è chiaro l'x86 rimane una delle peggiori architetture mai concepite da mente umana, ma tant'è il peggio si accompagna al peggio [Wintel]

[cdimauro]

Originariamente inviato da tomminno

Semplicemente motivi di efficienza e semplicità architetturale tanto cari alla filosofia RISC.

Sì, ma qui stiamo parlando di CISC, che hanno una filosofia completamente diversa e che... alla fine è sopravvissuta.

Operazioni memoria memoria comportano un supporto da parte di entrambi gli operandi di tutte le possibili combinazioni di indirizzamento, ovvero tanti opcode da gestire.

Vero, ma bisogna vedere in che modo sono strutturati gli opcode.

Se prendiamo il modello x86, che NON ha operazioni memoria-memoria (se escludiamo i casi particolari rappresentati dalle speciali istruzioni che lavorano su "stringhe", che però non hanno modalità d'indirizzamento, in quanto è codificato internamente), vediamo che l'organizzazione è decisamente più incasinata e il decoder si complica non poco stando dietro alla quasi casualità della mappatura degli opcode e, soprattutto, alla presenza di un numero variabile prefissi.

La cosa è evidenziata anche nell'articolo da te citato:

Il motivo lo capirai meglio quando parlerò del Motorola 68020. L'architettura 68000 di per sé è abbastanza semplice da decodificare, ma purtroppo Motorola con lo 020 ha introdotto delle modalità d'indirizzamento mostrosamente complicate che, infatti, erano in grado di mettere in ginocchio anche il 68060 (primo processore superscalare per questa famiglia, le cui prestazioni erano molto elevate in caso di istruzioni semplici come quelle del 68000 appunto).

Poi è chiaro l'x86 rimane una delle peggiori architetture mai concepite da mente umana, ma tant'è il peggio si accompagna al peggio [Wintel]

Con un amighista sfegatato sfondi una porta aperta.

[misterx]

possiamo asserire che in definitiva minix tutto quello che fa è:

- gestire i processi in modo che a turno tutti usino la CPU
- mettere a dormire i processi nel momento in cui questi faoono I/O
- prendere i messaggi di un processo mittente e portali al processo destinatario che sia driver, server etc....

In definitiva scrive nei PCB dei processi e legge e scrive negli stack dei vari processi in quanto solo il kernel può farlo

[cdimauro]

Sostanzialmente sì.

[misterx]

grazie cdmauro

parlando della fork() il cui scopo è quello di duplicare processi:

while (TRUE){
    type.....prompt();
    read...command(command, paramaters);

    if(fork() != 0){

        waitpid(-1, &status, 0);
    } else {
        execve(command, parameters, 0)
    }
}

questo programma che dovrebbe essere la shell di unix, se eseguito passando come argomento un comando + parametri si comporta nel modo seguente:
una volta incontrata la fork() questa ritorna un PID=0 e quindi viene eseguito il ramo dell'else che mandando in esecuzione la execve(...) fa iniziare una duplicazione completa in memoria del processo chiamante.

In memoria ora si hanno due processi identici però:
il processo "padre" ora ha PID != 0 e quindi rimane in attesa sulla waitpid(...)


domande:
- il processo figlio rimane con PID = 0 ?
E quindi si comporta ora come se fosse un padre ?
Come si potrebbe far generare al processo figlio un ulteriore processo figlio ?



Spero di essere stato chiaro

[cdimauro]

Più o meno. Immagino che PID sia una variabile locale che dovrebbe contenere il PID del processo figlio, ma non la vedo nel sorgente che hai postato.

[misterx]

Originariamente inviato da cdimauro

Più o meno. Immagino che PID sia una variabile locale che dovrebbe contenere il PID del processo figlio, ma non la vedo nel sorgente che hai postato.

purtroppo ho solo quel frammento di codice. Cmq si, PID viene ritornato dalla fork()

[cdimauro]

Allora posso soltanto aggiungere che ogni processo (padre, figlio / figli) ha un proprio PID (mai uguale a zero).

[misterx]

Originariamente inviato da cdimauro

Allora posso soltanto aggiungere che ogni processo (padre, figlio / figli) ha un proprio PID (mai uguale a zero).

però all'inizio e cioè quando esiste solo il processo padre hai PID = 0 e poi via via il padre diventa != 0 e il figlio varrà sempre zero, giusto ?

[cdimauro]

Allora ti riferisci necessariamente alla variabile che conterrà il PID.

Quindi il codice sarà qualcosa del tipo:

PID = fork();
if(PID != 0){
    waitpid(-1, &status, 0);
}
else {
    execve(command, parameters, 0)
}

e quindi hai ragione.

[misterx]

grazie

ho preso del codice postato da un utente e dopo compilazione l'ho lanciato più volte

#include <stdio.h>
#include <sys/types.h>
void main()
{
	pid_t pid;
	printf (“Prima della fork: PID = %d\n”, getpid());
	pid = fork();
	if (pid==0) /* PROCESSO FIGLIO*/
	{
		printf (“FIGLIO: PID = %d\n”, getpid());
		exit(0);
	}
	else /* PROCESSO PADRE */
	{
		printf (“PADRE: PID = %d\n”, getpid());
		printf (“PADRE: PID DEL FIGLIO = %d\n”, pid);
		exit(0);
	}
}

digitando ps mi viene mostrato il PID della shell sh che è 92 mentre il PPID di questo programma mandandolo in esecuzione è 92 e il suo PDI è 219.
Quel 92 mi fa capire che il programma che io ho chiamato test è figlio di sh e quindi quando la shell manda in esecuzione test duplica se stessa.
Lanciando test più volte si nota il seguente output:

primo caso
Prima della fork: PID = 219
FIGLIO: PID = 220
PADRE: PID = 219
PADRE: PID DEL FIGLIO = 220

secondo caso
Prima della fork: PID = 227
PADRE: PID = 227
PADRE: PID DEL FIGLIO = 228
FIGLIO: PID = 228


sembrerebbe che si ha una duplicazione della shell e che quindi test diviene una copia della shell ma a sua volta una volta in esecuzione test, questo viene duplicato immediatamente nel primo caso e successivamente nel secondo caso: è dovuto allo scheduler questo effetto ?

[cdimauro]

Sì, è corretto.

[misterx]

una domanda di assembly

L1: .data 4 0 ! dichiara la variabile L1 di 4 byte inizializzata a zero
move al, (L1) ! copia il contenuto di L1 nel registro al della CPU
mov (L1), ah ! copia l'indirizzo contenuto nel registro ah nella variabile L1 ???
mov eax, L1 ! copia in eax l'indirizzo in memoria occupato da L1 ?????

le righe in rosso non mi sono molto chiare

grazie

[malocchio]

Originariamente inviato da misterx

una domanda di assembly

L1: .data 4 0 ! dichiara la variabile L1 di 4 byte inizializzata a zero
move al, (L1) ! copia il contenuto di L1 nel registro al della CPU
mov (L1), ah ! copia l'indirizzo contenuto nel registro ah nella variabile L1 ???
mov eax, L1 ! copia in eax l'indirizzo in memoria occupato da L1 ?????

le righe in rosso non mi sono molto chiare

grazie

Mi sembra strano che tu non abbia capito le ultime due righe, visto che hai capito la seconda!

L1 è un "nome" a cui l'assembler (o il linker? non ricordo) sostituisce un numero, che è un indirizzo di memoria.

Supponiamo che ad L1 sia associato il numero 0xABC
Se tu provi a sostituire

0xABC: .data 4 0 ! riserva 4 byte a partire dall'indirizzo 0xABC
move al, (0xABC) ! copia il contenuto della cella di indirizzo 0xABC in AL
mov (0xABC), ah ! scrive nella cella d'indirizzo 0xABC il contenuto di AH
mov eax, 0xABC ! copia in EAX 0xABC

Non è troppo corretto dire che la prima riga dichiara una variabile. Piuttosto riserva uno spazio di memoria di 4 byte (azzerati). L1 è un nome che tu programmatore usi per riferirti all'indirizzo di memoria associato ad esso (lo spazio).
Le parentesi tonde in assembly funzionano come l'asterisco in C.

Forse l'ultima riga può essere poco intuitiva. Pensa subito a cos'è L1. Un nome. Il nome viene trasformato nella fase di assembling (si dice così?) in un numero (che è un indirizzo di memoria), ben definito. Quindi potendo andare a guardare il codice assemblato tu vedrai l'ultima istruzione proprio come "scrivi in EAX 0xABC", una costante numerica, che è l'indirizzo di memoria che l'assembler durante il suo lavoro ha deciso di associare ad L1.

Il discorso gira un po', spero di averti aiutato

[misterx]

Originariamente inviato da malocchio

Le parentesi tonde in assembly funzionano come l'asterisco in C.

grazie per la risposta!

scritto così:
mov al, (L1)
mi è chiaro in quanto come tu mi dici è come se scrivessi
al = *L1
tipo, se L1 è all'indirizzo di memoria 100 e tale indirizzo contiene 20, dopo la mov al, (L1) il registro al conterrà 20

scritto così però:
mov (L1), ah
mi dice molto meno però dovrebbe essere ancora:
*L1 = qualcosa
ma questo qualcosa potrebbe essere di fatto o un indirizzo o un valore ?

esempio:
mov (L1), ah

se ah contiene 28, a questo punto l'istruzione qui sopra assegna all'indirizzo di memoria 100 relativo a L1 28 ?

E se scrivessi invece:
mov L1, ah
cambierebbe l'indirizzo di L1 da 100 a 28 ?

scusa ma ho un pò di confusione

grazie

[malocchio]

Originariamente inviato da misterx

grazie per la risposta!

scritto così:
mov al, (L1)
mi è chiaro in quanto come tu mi dici è come se scrivessi
al = *L1
tipo, se L1 è all'indirizzo di memoria 100 e tale indirizzo contiene 20, dopo la mov al, (L1) il registro al conterrà 20

Tutto giusto, attenzione però che L1 non è ALL'INDIRIZZO di memoria, in realtà è L'INDIRIZZO di memoria, L1 diventa proprio un numero!
Ti correggo pignolamente perché sbagliare anche una preposizione potrebbe portare confusione...

Originariamente inviato da misterx

scritto così però:
mov (L1), ah
mi dice molto meno però dovrebbe essere ancora:
*L1 = qualcosa
ma questo qualcosa potrebbe essere di fatto o un indirizzo o un valore ?

MM, allora in realtà mi rendo conto che l'asterisco del C può portare ad incomprensioni: nel C di solito lo usi per accedere alla cella di memoria il cui indirizzo è contenuto in un'altra cella (la variabile puntatore), mentre qui accedi all'indirizzo L1. Ho introdotto l'asterisco perché serve per accedere all'indirizzo specificato, ma in questo caso nell'assembly l'indirizzo è un numero costante, nel C (DI SOLITO) è una variabile puntatore.

Attenzione però che essenzialmente non c'è differenza tra le parentesi tonde in assembly e l'asterisco in C, solo che qui stiamo parlando di due casi diversi.

Infatti:

mov ah, (bx)

qui vediamo un uso corretto delle parentesi tonde, in cui però l'indirizzo non è specificato come costante numerica (l'L1 di prima), ma è contenuto nel registro BX (gli indirizzi vengono memorizzati in registri a 16/32/64 bit a seconda dell'architettura, ma questo adesso non ci interessa molto), durante l'esecuzione del programma. Anche qui però non possiamo parlare di "puntatore" come lo intendiamo solitamente nel C, perché in C il puntatore è una VARIABILE IN MEMORIA, che contiene l'indirizzo di un'altra variabile. Qui, per quanto ne sappiamo, l'indirizzo è in BX. Quindi è un po' diversa.

Originariamente inviato da misterx

esempio:
mov (L1), ah

se ah contiene 28, a questo punto l'istruzione qui sopra assegna all'indirizzo di memoria 100 relativo a L1 28 ?

Sì, considerando l'indirizzo 100 come esempio succede proprio così. In C è traducibile nell'istruzione

*(100) = ventotto

con l'unica differenza che ventotto è una variabile, AH è un registro.
In realtà in C non vedrai mai quest'istruzione, perché non puoi decidere a tempo di compilazione un indirizzo specifico a cui vuoi accedere (se non in casi estremi; di solito non puoi perché il sistema operativo non ti permette di accedere a celle di memoria che non ti "appartengono", come processo in esecuzione).
Le variabili globali in un programma C sono associate ciascuna ad un'etichetta come L1. Infatti, durante il processo di compilazione, esse sono tradotte in indirizzi!

Originariamente inviato da misterx

E se scrivessi invece:
mov L1, ah
cambierebbe l'indirizzo di L1 da 100 a 28 ?

scusa ma ho un pò di confusione

grazie

Assolutamente No! Pensa ancora "L1 è un numero". Rendiamo più leggibile l'istruzione scrivendola in un linguaggio di prog degno di tal nome:

100 = ventotto

No, a questo punto vedi che non ha senso assegnare alla costante 100 il valore 28..
E' anche traducibile in (utile se hai un minimo di esperienza nei puntatori, e penso che tu ce l'abbia)

&L1 = ventotto

Quando usi l'ampersend ti riferisci all'indirizzo in cui è contenuta una variabile, no? Ben non vedrai mai a sinistra di un uguale l'operatore &

Se non ti è totalmente chiara una qualsiasi cosa chiedi assolutamente!