slacky.eu

Qualcuno mi saprebbe dire in che consiste la differenza esatta fra un feature del sistema implementata in kernel space e la stessa implementata in user space

se ti può servire..
http://www.lilik.it/~mirko/gapil/gapils ... -80001.1.2

Beh, in kernel space hai: Totalità dei permessi e maggiore velocità. Ovviamente, più instabilità. Se fai qualche cappella.... ti tocca fare reboot


ciao

Ok grazie

Totalità dei permessi e maggiore velocità. Ovviamente, più instabilità.

Siamo proprio sicuri?

touchstyle ha scritto:

Totalità dei permessi e maggiore velocità. Ovviamente, più instabilità.

Siamo proprio sicuri?

Usare l'user-space aggiunge di fatto un muro tra l'hardware e il software ... difatti il software in user-space interagisce con l'hardware solo attraverso il kernel. Basta un confronto tra l'interfaccia grafica di windows e quella di linux, la prima a livello kernel, la seconda implementata come server in user-space. L'interfaccia di windows è veloce, ma basta che la gui di un programma faccia male il suo lavoro che salta tutto per aria... Il server X è "più lento" (già il fatto che sia un server lo suggerisce), ma se crasha una gui, basta un ctrl-alt-f6, ci si logga e si killa il programma, o nel peggiore dei casi X ... il kernel e tutti i programmi che non utilizzano X restano in piedi.
Totalità dei permessi direi no, kernel-space e user-space astraggono dal concetto di permessi del kernel e permessi degli user.

Instabilità perchè, se scazzi una dichiarazione, se ti ritrovi un puntatore NULL dove non lo vuoi, oppure ti sbagli con un ciclo, ahimè ti tocca riavviare.
Non oso pensare a quanto siano difficili le operazioni di debugging ( immagino... accendo il pc, carico il mio modulo e poi freeza tutto... ora vorrei vedere chi sa risalire a cosa è successo ).

Permessi?
In Kernel-space, praticamente non esistono. Per fare un confronto... root viene dopo il kernel.

ciao

Non oso pensare a quanto siano difficili le operazioni di debugging ( immagino... accendo il pc, carico il mio modulo e poi freeza tutto... ora vorrei vedere chi sa risalire a cosa è successo ).

un rimedio per questo potrebbe essere usare User Mode Linux

Kernel space e User space differiscono nel modo in cui viene fatta funzionare la CPU. Le CPU Intel posseggono la capacità di operare in 4 modalità distinte: ring 0, ring 1, ring 2, ring 3. Più basso è il ring, maggiori sono le operazioni concesse, più alto è il ring, minori sono le cose che si possono fare mediante la CPU. In un sistema GNU il kernel viene eseguito a ring 0, i programmi user space a ring 3. In un architettura a micro-kernel verrebbero utilizzati tutti e 4 i livelli.

Questo controllo eseguito in hardware permette che programmi scritti male o maliziosamente non possano distruggere l'intero sistema. Se infatti un programma volesse, per esempio, andare a risettare il vettore delle interruzioni, assumendo così il controllo del sistema, solleverebbe subito un'eccezione sulla CPU. L'eccezione sollevvata dalla CPU andrebbe subito riferita al kernel, il kernel manderebbe immediatamente un segnale di SIGSEGV al processo pazzo, il processo pazzo, ricevuto SIGSEGV, verrebbe terminato all'istante.

Sotto Linux l'intera GUI ( server X ) viene eseguito come processo utente; diversamente invece accade su Windows.
Una grafica eseguita a livello utente permette una maggiore immunità del sistema ai crash: minori sono le cose che si fanno a livello kernel, maggiore sarà la robustezza del sistema quando qualcosa andrà storto. L'implementazione del sistema grafico in user space introduce però un inevitabile overhead dovuto ai continui context switch eseguiti dal server X; fondamentalmente questa è la ragione per cui sotto Windows la grafica è più veloce che non sotto Linux.

Gli utenti windows saranno contenti di una grafica più fluida, ma se qualcosa andrà storto potranno staccare la spina.
Gli utenti GNU avranno una grafica leggermente più lenta ma incredibilmente scalabile ( KDE, GNOME, Xfce ....! ) e più robusta rispetto ai disastri. Io preferisco la seconda !

TheSnowBoarder ha scritto:Kernel space e User space differiscono nel modo in cui viene fatta funzionare la CPU. Le CPU Intel posseggono la capacità di operare in 4 modalità distinte: ring 0, ring 1, ring 2, ring 3. Più basso è il ring, maggiori sono le operazioni concesse, più alto è il ring, minori sono le cose che si possono fare mediante la CPU. In un sistema GNU il kernel viene eseguito a ring 0, i programmi user space a ring 3. In un architettura a micro-kernel verrebbero utilizzati tutti e 4 i livelli.

come mai i due ring intermedi (2 e 4) non vengono utilizzati??? per usi futuri??
cioè: perchè non usare ring 4 invece che 3 per lo user space? c'è un motivo tecnico???

M.

absinthe ha scritto: come mai i due ring intermedi (2 e 4) non vengono utilizzati??? per usi futuri??
cioè: perchè non usare ring 4 invece che 3 per lo user space? c'è un motivo tecnico???

Nell'architettura del kernel Linux i ring intermedi 1 e 2 non vengono utilizzati perché Linux è strutturato monoliticamente: un unico grosso binario al cui interno sono implementate per mezzo di routine tutte le funzioni di cui ha bisogno un sistema per funzionare: gestione della memoria, driver dei dischi, gestione del multitasking etc. In questo modello la gestione sulla sicurezza del codice eseguito è implementata in modo binario. Kernel mode: puoi fare tutto; user mode: non puoi fare quasi nulla. Non esistono compromessi; o tutto o niente.
Questo significa che una qualsiasi componente che gira all'interno del kernel ha i privileggi per compiere una qualsiasi azione: se ci fosse un bug in una di queste componenti ( file system, driver di dispositivo ...) i risultati potrebbero essere imprevedibili e dannosi.


Le cose vanno diversamente in un architettura a microkernel. In questo genere di architettura i compiti eseguiti dal kernel sono "gerarchizzati" ed eseguiti per mezzo di più "processi" separati l'un l'alro. A ring 0 viene fatto girare un kernel minuscolo la cui principale attività consiste nel recapitare i messaggi scambiati tra i "processi kernel" eseguiti a ring più alto. Questi "processi kernel" si comportano esattamente come dei server: ricevono un compito richiestogli da qualcuno, lo eseguono e restituiscono al mittente il risultato. Questa architettura ha diversi vantaggi rispetto al kernel monolitico: le diverse funzioni proprie di un OS vengono isolate in più processi indipendenti l'un l'altro su ring diversi, minimizzando così la possibilità di catastrofi nucleari dovute ad errori nel codice. Un sistema a microkernel è già intrinsecamente un sistema distribuito: non importa che i serventi girino sulla stessa macchina; l'importante e che vi sia qualcuno che mandi loro dei messaggi.

Malgrado sulla carte un microkernel appaia come una cosa meravigliosa, nella pratica succede che il suo sviluppo sia parecchio complesso: HURD , il microkernel GNU ancora non si è visto in fase stabile.

Il progetto GNU preferi Linux ad HURD per il proprio sistema operativo perché Linux funzionava, HURD no.

A proposito di micro-kernel è stata rilasciata da poco l'ultima release di Minix!

http://www.minix3.org/

TheSnowBoarder ha scritto:HURD , il microkernel GNU ancora non si è visto in fase stabile.

Il progetto GNU preferi Linux ad HURD per il proprio sistema operativo perché Linux funzionava, HURD no.

il bello è che sono passati quasi 15 anni e la situazione è ancora la stessa .

grazie!

comunque io intendevo semplicemente... se ring 4 è più restrittivo di ring 3 perchè un binario user-space non è implementato per girare a ring 4 (non so se è una ca...ta: so ignorante in materia)

M.

absinthe ha scritto:grazie!
comunque io intendevo semplicemente... se ring 4 è più restrittivo di ring 3 perchè un binario user-space non è implementato per girare a ring 4 (non so se è una ca...ta: so ignorante in materia)
M.

ma se ci sono in tutto 4 ring (0,1,2,3) il meno restrittivo sarà il 3,no?
ring 4 non esiste...
occhio! in informatica si conta partendo da 0!