nel kernel e nello spazio utente

Question

Ora so che lo sviluppo di un'app che va nello spazio del kernel dovrebbe essere evitato - è difficile fare il debug, complesso ecc .... con quello fuori dalla tabella quali sono alcuni vantaggi nello spostare un'app da spazio utente per il kernel? dopotutto se non ci fossero più lati non sarebbe mai stato fatto ... quali sono alcuni?

Answer 1

Alcune possibili vantaggi:

sistema

• chiamate potrebbe essere veloci (cioè minori latenze), la CPU non deve passare dalla modalità applicazione in modalità kernel. (Questo non è necessariamente vero, in quanto la CPU potrebbe fare una distinzione più precisa di "spazio utente" e "spazio kernel". Le CPU Intel x86, ad esempio, hanno un modello ad anello che comprende 4 livelli di privilegio distinti.) ¹⁾

• potresti ottenere accesso diretto all'hardware del sistema tramite la memoria e le porte I/O.

• si potrebbe essere in grado di sopprimere commutazione compito, se avete bisogno di fare qualcosa senza essere interrotto

• si potrebbe essere in grado di meccanismi di sicurezza eludere imposti dal sistema operativo (ad esempio, lettura/modifica memoria di altri processi). (Malware potrebbe approfittare di questo se viene installato come un driver di periferica in modalità kernel.)

(E, naturalmente, come sapete, ci sono molti molti svantaggi e rischi per la sicurezza. La distinzione tra spazio di applicazione e lo spazio del kernel è lì per buoni motivi.)

---

¹⁾ veda, ad esempio l'articolo Making system calls from kernel space from Linux mag:

Ad esempio, un server Web ad alte prestazioni potrebbe desiderare di risiedere nel kernel per aumentare il throughput e la latenza più bassa. Tuttavia, v'è anche un compromesso di sicurezza [...]

Answer 2

Hai la possibilità per un piccolo bug nel tuo programma di scrivere tutta la memoria e danneggiare l'intero sistema e tutti i suoi processi e funzioni. Se sei fortunato, il sistema si bloccherà.

Answer 3

Alcuni dei motivi che mi vengono in mente durante la ricerca di opzioni vale a dire la modalità kernel vs modalità utente:

1) Quando l'elaborazione è dedicato richiesto e vogliamo utilizzare le utilità integrate nel sistema operativo. Ad esempio: se dovessimo progettare un server IO. Qui le latenze sono al ritmo di 1-5 ms. Non si possono aspettare interruttori di contesto a causa di compromessi in modalità utente kernel. Ma se si deve fare affidamento sul framework IP TCP dato dal kernel. Deve essere implementato in modalità Kernel collegando strettamente il framework Network/TCP/IP e il framework di trasporto previsto.

2) Quando si desidera disporre completamente del framework di pianificazione.Mentre questo è intuitivamente disponibile utilizzando varie chiamate di sistema e framework pthread. Tuttavia, se il tuo prodotto/thread possiede completamente il processore, allora ci sono casi di deadlock o livelock da cui potresti voler recuperare. In tali scenari è necessario un framework che tenga conto del tempo impiegato da ciascun thread. Questo non può essere fatto dalla lan dell'utente e quindi è richiesto il supporto dal programmatore del kernel/sottosistema di pianificazione.

3) Quando si desidera sovraccaricare l'accesso alla memoria, di nuovo in ambienti in cui le risorse sono dedicate per operazioni particolari. Ha senso sovrapporre la memoria fisica/memoria del kernel per i thread virtuali.

4) Quando si desidera virtualizzare l'accesso al disco per aggiungere ridondanza o migliorare le prestazioni di lettura/scrittura.

Ci potrebbero essere molte più ragioni, ma la causa principale centrale:

1) Ogni volta che si vuole ridurre i livelli di prestazioni si sposta al kernel. Poiché il kernel aggiunge un framework di virtualizzazione per condividere equamente le risorse (cpu, ram, network, disk).

2) Ogni volta che si desidera utilizzare l'infrastruttura del kernel da utilizzare che è difficile da portare all'utente lan (Tcp/ip o shceduler).