Як реалізувати драйвер драйвера файлової системи в Linux? [зачинено]


15

Припустимо, що я винайшов нову файлову систему, і тепер я хочу створити для неї драйвер файлової системи.

Як би я реалізував цей драйвер файлової системи, це робиться за допомогою модуля ядра?

І яким чином драйвер файлової системи може отримати доступ до жорсткого диска, чи повинен драйвер файлової системи містити код для доступу до жорсткого диска, чи Linux містить драйвер пристрою для доступу до жорсткого диска, який використовується всіма драйверами файлової системи?

Відповіді:


24

Так, файлові системи в Linux можуть бути реалізовані як модулі ядра. Але є також інтерфейс FUSE (Filesystem в USErspace), який може дозволити звичайному процесу в просторі користувачів діяти як драйвер файлової системи. Якщо ви прототипуєте нову файлову систему, то її реалізація спочатку за допомогою інтерфейсу FUSE може полегшити тестування та розробку. Після того, як внутрішня частина файлової системи буде відпрацьована у формі FUSE, ви можете почати реалізовувати її оптимізовану за продуктивністю версію модуля ядра.

Ось основна інформація про реалізацію файлової системи у просторі ядра. Він досить старий (з 1996 року!), Але це, принаймні, повинно дати тобі основне уявлення про те, що потрібно робити.

Якщо ви вирішили перейти до маршруту FUSE, ось libfuse, довідкова реалізація на стороні користувача інтерфейсу FUSE.

Драйвер файлової системи як модуль ядра

По суті, функції ініціалізації модуля драйвера файлової системи потрібно просто викликати register_filesystem()функцію та надати їй як параметр структуру, яка включає вказівник функції, який ідентифікує функцію у вашому драйвері файлової системи, яка буде використана як перший крок у визначенні вашої файлової системи тип та монтаж. На цьому етапі більше нічого не відбувається.

Коли файлова система монтується, або тип файлової системи визначений, щоб відповідати вашому драйверу, або виконується автоматичне виявлення типу файлової системи, шар віртуальної файлової системи ядра (VFS для короткого) викликає цю функцію. Це в основному говорить: "Ось вказівник на представлення рівня ядра стандартного блокового пристрою Linux. Погляньте на це, подивіться, чи це щось, з чим ви можете впоратися, а потім скажіть, що ви можете з цим зробити".

У цей момент ваш драйвер повинен прочитати все, що йому потрібно, щоб перевірити, чи є правильним драйвером для файлової системи, а потім повернути структуру, яка включає вказівники на подальші функції, які ваш драйвер може виконувати з цією конкретною файловою системою. Або якщо драйвер файлової системи не розпізнає дані на диску, він повинен повернути відповідний результат помилки, і тоді VFS або повідомить про помилку в просторі користувачів, або - якщо виконується автоматичне виявлення типу файлової системи - запитає іншу файлову систему драйвер спробувати.

Інші драйвери ядра нададуть стандартний інтерфейс блочного пристрою, тому драйверу файлової системи не доведеться реалізовувати апаратну підтримку. В основному, драйвер файлової системи може читати і записувати дискові блоки за допомогою стандартних функцій рівня ядра з наданим на нього вказівником пристрою.

Шар VFS очікує, що драйвер файлової системи зробить доступними ряд стандартних функцій для рівня VFS; декілька з них є обов'язковими для того, щоб рівень VFS зробив щось важливе з файловою системою, інші - необов’язкові, і ви можете просто повернути NULL замість вказівника на таку необов'язкову функцію.


1
Це досить хороша відповідь, хоча, щоб повністю відповісти на зазначене питання, вам також потрібно буде трохи сказати про функціональність, який забезпечує рівень блокового пристрою для створення рівня файлової системи.
kasperd

Я якось на це натякав на біт "ось вказівник на стандартний блок пристрою", але добре; Я на цьому розширився.
telcoM

Ця відповідь, зокрема опис того, що відбувається в якому порядку, божественна. Чи можу я прочитати якусь книгу / веб-сайт, який містить такі описи для всіх "як працює Linux"?
Адам Барнс

Можливо, вас зацікавлять внутрішні протоколи ядра Linux або драйвери пристроїв Linux, 3-е видання . І звичайно, є можливість зчитування фактичного вихідного коду.
telcoM

5

Так, драйвер ядра може керувати файловою системою.

Найкраще рішення для макети прототипу файлової системи - використання FUSE. І після того, як ви можете подумати про перетворення його на драйвер ядра.

Wikipedia => https://en.wikipedia.org/wiki/Filesystem_in_Userspace

Джерело => https://github.com/libfuse/libfuse

підручник => https://developer.ibm.com/articles/l-fuse/


0

Так, це зазвичай робиться за допомогою драйвера ядра, який може бути завантажений як модуль ядра або скомпільований у ядро.

Ви можете перевірити подібні драйвери файлової системи та як вони працюють тут .

Ці драйвери, ймовірно, використовують внутрішні функції ядра для доступу до пристроїв зберігання даних як блоки байтів, але ви також можете використовувати блок-пристрої, як їх виявляють драйвери в блокових пристроях та папках символьних пристроїв .


0

Ви можете використовувати запобіжник, створити файлову систему user-land або написати модуль ядра. Це простіше зробити з запобіжником, оскільки у вас є вибір мов, і ядро ​​не буде збито (а отже, і вся система).

Модулі ядра можуть бути швидшими, але перше правило оптимізації: Не робіть цього, доки ви не протестували робочий код. Друга така: Не робіть цього, доки у вас не з’явиться доказ, що це занадто повільно. І третє: Не тримайте його, якщо у вас немає доказів того, що це робить його швидшим / меншим.

І так, ядро ​​вже має драйвери для апаратного забезпечення, ви не повторно реалізовуєте їх.


У FUSE є і інші мінуси, крім продуктивності: важко використовувати його для вашої кореневої файлової системи. (Можливо, з initrd, але двійковий код FUSE не може бути звільнений після завантаження, тому що він все-таки виконується з
Пітер Кордес,

1
@PeterCordes Це неможливо було звільнити , але це не означає, що його не можна від’єднати. Якщо на нього все ще є посилання, воно зберігатиметься в пам’яті незалежно від того, ви залишили initramfs чи видалили базовий двійковий файл чи ні.
ліс

@forest: правильно, тому ви не можете вимкнути інітард після pivot_root, оскільки в initramfs все ще є зайняті.
Пітер Кордес

Нормальний запуск /initз initramfs (я думаю) буде execve /initпісля pivot_root, щоб передати управління реальним кореневим FS /init. Але двійковий файл FUSE не міг замінити себе execve, якщо доступ до кореневого FS залежав від процесу FUSE у відповідь на ядро. Ну, можливо, спочатку грунтуючи кеш сторінки, але це не здається надійним.
Пітер Кордес
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.