Supponiamo di aver inventato un nuovo file system e ora voglio creare un driver di file system per esso.
Come implementare questo driver di file system, questo viene fatto usando un modulo kernel?
E come può il driver del file system accedere al disco rigido, se il driver del file system contiene codice per accedere al disco rigido o Linux contiene un driver del dispositivo per accedere al disco rigido utilizzato da tutti i driver del file system?
Risposte:
Sì, i filesystem in Linux possono essere implementati come moduli del kernel. Ma c'è anche l'interfaccia FUSE (Filesystem in USErspace), che può consentire a un normale processo di spazio utente di fungere da driver di filesystem. Se stai prototipando un nuovo filesystem, implementarlo prima utilizzando l'interfaccia FUSE potrebbe semplificare i test e lo sviluppo. Una volta elaborati gli interni del filesystem in formato FUSE, è possibile iniziare a implementare una versione del modulo del kernel ottimizzata per le prestazioni.
Ecco alcune informazioni di base sull'implementazione di un filesystem nello spazio del kernel. È piuttosto vecchio (dal 1996!), Ma questo dovrebbe almeno darti un'idea di base per il tipo di cose che devi fare.
Se si sceglie di accedere al percorso FUSE, ecco libfuse, l'implementazione di riferimento del lato spazio utente dell'interfaccia FUSE.
Fondamentalmente, la funzione di inizializzazione del modulo del driver del file system deve semplicemente chiamare una register_filesystem()funzione e assegnarle come parametro una struttura che include un puntatore a funzione che identifica la funzione nel driver del file system che verrà utilizzata come primo passo nell'identificazione del file system digitare e montarlo. Non succede più nulla in quella fase.
Quando viene montato un filesystem e viene specificato il tipo di filesystem in base al proprio driver, oppure viene eseguito il rilevamento automatico del tipo di filesystem, il layer Virtual FileSystem del kernel (VFS in breve) chiamerà quella funzione. Sostanzialmente dice "Ecco un puntatore a una rappresentazione a livello di kernel di un dispositivo a blocchi Linux standard. Dai un'occhiata, vedi se è qualcosa che puoi gestire, e poi dimmi cosa puoi fare con esso."
A quel punto, il tuo driver dovrebbe leggere tutto ciò di cui ha bisogno per verificare che sia il driver giusto per il filesystem, e quindi restituire una struttura che include puntatori a ulteriori funzioni che il tuo driver può fare con quel particolare filesystem. Oppure, se il driver del file system non riconosce i dati sul disco, si suppone che restituisca un risultato di errore appropriato, quindi VFS segnalerà un errore nello spazio utente o - se viene eseguito il rilevamento automatico del tipo di file system - chiederà un altro file system autista da provare.
Gli altri driver nel kernel forniranno l'interfaccia standard del dispositivo a blocchi, quindi il driver del filesystem non dovrà implementare il supporto hardware. Fondamentalmente, il driver del filesystem può leggere e scrivere blocchi di dischi usando le funzioni standard a livello di kernel con il puntatore del dispositivo fornito.
Il livello VFS prevede che il driver del file system renda disponibili una serie di funzioni standard per il livello VFS; alcuni di questi sono obbligatori affinché il livello VFS possa fare qualcosa di significativo con il filesystem, altri sono opzionali e puoi semplicemente restituire un NULL al posto di un puntatore a tale funzione opzionale.
Sì, un driver del kernel può gestire un file system.
La migliore soluzione per simulare, prototipare un file system è usare FUSE. E dopo puoi pensare di trasformarlo in un driver del kernel.
Wikipedia => https://en.wikipedia.org/wiki/Filesystem_in_Userspace
Fonte => https://github.com/libfuse/libfuse
un tutorial => https://developer.ibm.com/articles/l-fuse/
Sì, questo sarebbe normalmente fatto usando un driver del kernel che può essere caricato come modulo del kernel o compilato nel kernel.
Puoi controllare driver di filesystem simili e come funzionano qui .
Questi driver probabilmente usano le funzioni interne del kernel per accedere ai dispositivi di archiviazione come blocchi di byte, ma è anche possibile utilizzare i dispositivi a blocchi esposti dai driver nelle cartelle dei dispositivi a blocchi e dei caratteri .
È possibile utilizzare fuse per creare un file system utente-land o scrivere un modulo del kernel. È più facile avere a che fare con miccia, dato che hai una scelta di lingue e non bloccherà il kernel (e quindi l'intero sistema).
I moduli del kernel possono essere più veloci, ma la prima regola di ottimizzazione è: non farlo finché non hai testato il codice di lavoro. Il secondo è simile: non farlo finché non si ha la prova che è troppo lento. E il terzo: non tenerlo a meno che non si abbia la prova che lo rende più veloce / più piccolo.
E sì, il kernel ha già i driver per l'hardware, non è possibile implementarli nuovamente.
pivot_root, perché ci sono ancora inode occupati in initramfs.
/initiniziato da un initramfs verrà (credo) /initeseguito dopo pivot_root, per trasferire il controllo ai veri root FS /init. Ma un binario FUSE non potrebbe sostituirsi con execve se l'accesso al root FS dipendeva dal processo FUSE che rispondeva al kernel. Beh, forse innescando prima il pagecache, ma non sembra affidabile.