All'attuale versione 2.6.8 di sviluppo di Linux, non esiste una componente inserita in modo ufficiale per implementare la gestione dei file system in spazio utente. Perché si avverte la necessità di questo supporto anche al di fuori del kernel?
Come visto nella sezione 3.1, i file
system costituiscono la principale via di accesso a molti tipi di
risorse: dati fisici, informazioni virtuali, device
driver, socket
di comunicazione e così via. Se si riuscisse ad offrire la possibilità
di creare e manipolare file system in spazio utente, potenzialmente
ogni applicazione potrebbe definire le proprie risorse come particolari
tipi di file ed accedervi in modo trasparente. Inoltre tutti gli utenti
avrebbero la possibilità di implementare e caricare un file system
senza l'autorizzazione dell'ammini-stratore della macchina e soprattutto
senza che questa operazione costituisca una minaccia di sicurezza
per l'intero sistema: se fallissero alcune operazioni, l'effetto sarebbe
equivalente alla terminazione o al malfunzionamento di qualunque altro
programma. Questa situazione nei sistemi ben progettati come Linux
non implica la necessità di riavvio dell'intera macchina: i danni
derivati sarebbero limitati all'ambiente dell'utente proprietario
del processo bloccato. Altri vantaggi offerti da questa politica,
sono la possibilità di sfruttare funzioni di librerie non disponibili
al kernel, eseguire programmi se necessario, esaminare e correggere
il codice con un debugger convenzionale e trasferire la memoria
occupata dal processo sul dispositivo di swap del disco fisso. Grazie
a quest'ultima caratteristica, quando nessun processo accede file
system, si potrà liberare all'occorrenza la memoria principale permettendone
l'utilizzo.
Tuttavia l'integrazione di questa funzionalità comporta un notevole rallentamento nell'esecuzione delle operazioni sul file system in spazio utente. Come vedremo infatti, per ogni accesso ai dati vengono effettuati il triplo dei context-switch3.1 altrimenti necessari.