Il kernel è un processo?

1. In Linux, diciamo sempre che il primo processo è init(pid == 1). Ma perché non è il kernel (avvio) che imposta il sistema e crea il initprocesso. Il kernel è un processo?
2. Sappiamo che tutti i thread dello spazio utente sono radicati al processo init. E che dire dello scheduler e di altre cose del kernel, come la gestione della memoria?

Fondamentalmente, ciò che mi confonde è la struttura del kernel. Se è un processo, è un singolo processo o è costituito da più processi?

Risposte brevi:

1. No, non è un processo
2. I thread utente non sono rootati su init.

Init è solo il primo processo; non gestisce alcun processo o thread. Ne crea alcuni, usando il kernel syscalls fork () e exec.

Penso che tu abbia un'idea confusa di cosa sia un processo. non significa solo un po 'di esecuzione del codice. Sì, il kernel viene eseguito prima di init (e il boot loader anche prima). Ma un 'processo' ha una definizione specifica di:

• Funziona nello spazio utente
• Funziona con un ID processo
• Molte interazioni devono passare attraverso il kernel
• Tutte le risorse devono provenire dal kernel
• Deve essere programmato dal kernel

Quindi, una volta inizializzato il kernel, avvia init, che quindi genera qualsiasi altro processo indicato dalla sua configurazione.

Per quanto riguarda il n. 2, tutta la roba del kernel è, beh, nel kernel. Pensa al kernel come a una vasta area di codice. Ancora una volta, non un processo, ma un grande BLOB di codice. Parti del kernel si occupano della gestione della memoria, parti di essa con parti di pianificazione (come driver, ecc.) E parti di esso con processi di pianificazione.

Il kernel non si comporta affatto come un processo. Non viene pianificato, o viene eseguito per conto di un processo (il cosiddetto contesto del processo o il contesto dell'utente) o viene eseguito come risultato di un interrupt o di un'eccezione (il cosiddetto contesto di interrupt).

Detto questo, il kernel Linux genera thread del kernel per eseguire alcune attività o per evitare di eseguire qualcosa sul contesto di interruzione per troppo tempo (questo è ciò che fa il thread ksoftirqd, evitando latenze eccessive che potrebbero portare, ad esempio: alla caduta dell'audio, ...) .

Puoi vedere i thread del kernel sull'output del pscomando. Sono facilmente identificabili: il loro nome è tra parentesi. Alcuni di essi eseguono un'istanza per CPU, la CPU viene identificata con un numero dopo una barra, quindi [ksoftirqd / 0] è l'istanza di ksoftirqd sulla CPU 0.

Esistono concetti nei micro-kernel in cui varie parti del kernel sono effettivamente processi con la sentinella primaria che gestisce principalmente l'IPC.

Linux - nel bene e nel male - non è un sistema di micro kernel.

No, non è ... Il kernel (e le estensioni del kernel) vengono caricati direttamente nella memoria. Se c'è un codice non sicuro nel kernel, nulla si frappone tra esso e un grosso problema.

A parte questo, il kernel praticamente esegue / cambia tra i processi. Ovviamente qualcosa che esegue effettivamente i processi non sarà un processo stesso.

(tl; dr 1. no 2. parte del kernel / sua estensione)

Ninjalj ha scritto: "Il kernel non si comporta affatto come un processo. Non è programmato"

Bene, c'è il processo inattivo (sostanzialmente pid 0, anche se non è mostrato da nessuna parte) che è pianificato e circa sempre in uno stato eseguibile.

Cambio di contesto

❖ I processi sono gestiti da un blocco condiviso di codice OS chiamato kernel

▪ The kernel is not a separate process, but rather runs as part of a user process

❖ Il cambio di contesto passa il flusso di controllo da un processo a un altro e viene eseguito utilizzando il codice del kernel

Fonte: https://courses.cs.washington.edu/courses/cse351/19su/lectures/18/CSE351-L18-processes_19su.pdf , pagina 36