Int 80h interrompe un processo del kernel?

Question

Prima un po 'di conoscenze di base, questo è dal libro: Linux System Programming: Talking Directly to the Kernel and C Library

segnali sono un meccanismo per senso unico notifiche asincrone. Un segnale può essere inviato dal kernel a un processo, da un processo a un altro processo o da un processo a se stesso.

Il kernel di Linux implementa circa 30 segnali.

I segnali interrompono un processo in esecuzione, causando l'arresto di qualsiasi cosa sia e sta eseguendo immediatamente un'azione predefinita.

Ok avvicinarsi sempre più, da here citerò questa parte:

Sulla famiglia di microprocessori Intel, come il Pentium, int 80h è la lingua di codice op assembly per 80h di interrupt. Questo è l'interrupt di syscall su un tipico sistema Unix basato su Intel, come ad esempio FreeBSD. Consente ai programmatori di applicazioni di ottenere i servizi di sistema dal kernel Unix.

Non riesco proprio a realizzare la connessione nella mia testa. Così quando per esempio uso il metodo

write 

definito Posix, e quando viene compilato in assemblaggio, e poi ulteriormente assemblato in un codice oggetto e collegato a un eseguibile in una certa architettura che esegue Linux ... . a la chiamata di sistema è stata effettuata correttamente?

Io parto dal presupposto il codice compilato sarebbe simile a questa:

mov eax,4 ;code for system_write 
mov ebx,1 ;standard output 
mov ecx, memlocation; memlocation is just some location where a number of ascii is present 
mov edx, 20; 20 bytes will be written 

int 80h; 

Ok la mia domanda è esattamente a questo punto. Int 80h invierà un segnale al kernel/interromperà il kernel? Il kernel è solo un processo? (È il processo di inizializzazione?) Quando la cpu esegue int 80h, cosa succede esattamente? I registri sono già pieni di informazioni, (eax, ebx, ecx ed edx nel mio esempio ..), ma come vengono utilizzate queste informazioni?

Non riesco a stabilire la connessione tra la CPU, il kernel e cosa fa esattamente la CPU mentre esegue l'int 80h.

Posso immaginare che un codice risieda da qualche parte nella memoria che in realtà invia le informazioni richieste al driver di dispositivo ma a quale processo appartiene questo codice? (Sto assumendo il kernel ma il kernel è solo un processo?) E come fa l'istruzione int 80h a saltare a quel codice? È qualcosa che Linux deve implementare in qualche modo?

Answer 1

Il kernel è solo un processo? (È il processo di init?)

Il kernel è una bestia magica. Non è un processo. Il kernel non ha un PID a cui puoi fare riferimento.

Innanzitutto, vale la pena affermare (anche se è ovvio) che le istruzioni vengono eseguite sul processore: Pertanto, il processore esegue int 80h.

C'è qualcosa chiamato Interrupt Request Handler. Sono in qualche modo simili a un puntatore a funzione. Il processore ha una tabella di gestori di interrupt. Questa tabella è denominata Interrupt Descriptor Table (ovvero IDT) ed è a livello di sistema (ovvero, non tutti i processi hanno la propria tabella). I credo che questa tabella venga popolata dal kernel al primo avvio.

Quindi, cosa succede quando viene eseguito il int 80?

1. Il processore era in esecuzione nel livello di protezione dell'anello 3 (il livello normale per un processo). Per maggiori informazioni a livello di suoneria, vedere this.
2. Il processore passerà allo squillo 0, ovvero alla modalità kernel. In questa modalità, la protezione hardware è disabilitata. Ciò significa che il codice che verrà eseguito da ora in poi può fare tutto ciò che vuole. Scrivi ovunque nella memoria fisica, riscrivi la tabella dei descrittori degli interrupt, ecc.
3. Il processore passerà al codice situato nella Tabella dei descrittori di interrupt per l'interrupt 80h. Lo spazio disponibile per ogni interruzione nell'IDT è molto piccolo. Questo è il motivo per cui questo codice generalmente salterà di nuovo da qualche altra parte.
4. Il salto precedente presta il processore nella routine del kernel dedicata alla gestione di int 80h. Il processore non sta più eseguendo il codice del processo, ma ora sta eseguendo il codice del kernel.
5. Il kernel può controllare i registri e la memoria e determinare il motivo per cui è stato attivato l'interrupt. Capirà che volevi eseguire la chiamata di sistema write.
6. Il codice del kernel salterà di nuovo, questa volta nella routine che gestisce write. Il kernel eseguirà il suo codice per write.
7. Il kernel ha terminato di eseguire il suo codice. Indica al processore di tornare al livello di protezione dell'anello 3 e riprendere il processo.
8. Il processo dello spazio utente (noto anche come processo) viene ripristinato.

Answer 2

Quando la CPU esegue un'istruzione INT 80h, il processo attualmente in esecuzione su quella CPU è un processo utente ordinario. Come risultato dell'elaborazione di questa istruzione, la CPU passa dalla modalità utente alla modalità kernel. Il processo non cambia. Il processo corrente è ancora un processo utente ordinario, è appena in esecuzione in modalità kernel. Essere in modalità kernel dà al sistema il permesso di fare cose che il programma non può fare da solo. Il codice del kernel esegue quindi tutto ciò che è necessario per implementare la chiamata di sistema ed esegue un'istruzione IRET. Fa in modo che la CPU ritorni in modalità utente e avvii l'esecuzione del codice seguendo l'istruzione INT 80h.

Nota: se il codice della modalità kernel impiega abbastanza tempo per essere eseguito, in particolare se si blocca, lo scheduler potrebbe eseguire il kick-in e passare la CPU a eseguire un processo diverso. In questo caso il codice della modalità kernel deve attendere un'opportunità per completare il suo lavoro.

La maggior parte del tempo di CPU trascorso nel kernel è simile a questo, eseguendo chiamate di sistema nel contesto del processo che ha effettuato la chiamata di sistema. La maggior parte del tempo trascorso nel kernel è la gestione degli interrupt hardware. (Si noti che INT 80h è un interrupt software.) In tal caso l'interrupt viene eseguito nel contesto di qualsiasi processo in esecuzione al momento.La routine di interrupt fa tutto ciò che è necessario per riparare il dispositivo hardware che ha generato l'interrupt e quindi restituisce.

Mentre il kernel crea alcuni processi speciali per se stesso, questi processi hanno compiti molto specializzati. Non c'è il processo del kernel principale. Il processo di init in particolare non è un processo del kernel, è solo un normale processo utente.

Answer 3

Le vostre domande avranno risposta come richiesto. Raccomando di consultare l'interfaccia di programmazione del libro linux pagina 44. Tuttavia, le risposte brevi sono le seguenti. Ok la mia domanda è esattamente a questo punto. Int 80h invierà un segnale al kernel/interromperà il kernel?

No int 80h non solleva alcun segnale al kernel, invece si tratta di una voce in una tabella di interrupt

è Kernel un solo processo? (È il processo di init?)

No. Ora il kernel unix è un insieme di minacce (chiamate thread nativi) che possono avere 3 diversi tipi di mapping del kernel di processo.

Quando la cpu esegue l'int 80h, cosa succede esattamente? I registri sono già pieni di informazioni, (eax, ebx, ecx ed edx nel mio esempio ..), ma come vengono utilizzate queste informazioni?

int 80h è un'istruzione trap che trasferisce l'ambiente dalla modalità utente a kernel% eax contiene il numero di chiamata di sistema per scrivere da eseguire in modalità kernel. i contenuti di tutti gli altri registri sono memorizzati in memoria per essere memorizzati sulla modalità utente Non riesco a creare la connessione tra la CPU, il kernel e cosa fa esattamente la CPU mentre esegue l'int 80h.

80h è un trap per CPU che modifica l'ambiente da utente a kernel e salva i registri in memoria. significa che la CPU aiuta il kernel a fare qualcosa di utile con l'efficienza.

Posso immaginare che un codice risieda da qualche parte nella memoria che invia effettivamente le informazioni richieste al driver di dispositivo, ma a quale processo appartiene questo codice? (Sto assumendo il kernel ma il kernel è solo un processo?) E come fa l'istruzione int 80h a saltare a quel codice? È qualcosa che Linux deve implementare in qualche modo?

qui si sta chiedendo informazioni sui driver di periferica. la funzionalità dei driver è diversa dalla gestione di syscall. int 80h non funziona con i driver.