Действительно ли легче записать драйверы файловой системы в пространстве пользователя, чем в пространстве ядра?

Важно отметить, особенно для Linux, что экспериментальный может также означать «Код, который кто-то сбросил сюда, который в то время выглядел приемлемым, но не мог активно поддерживаться».

Я большой поклонник хранения файловых систем в пространстве пользователя, но должен также указать, что я большой энтузиаст микроядра . Я считаю практичным и предпочтительным хранить файловые системы в пространстве пользователя по следующим причинам:

Файловые системы пространства пользователя легче поддерживать

Найдите минутку, чтобы взглянуть на файловую систему ext3cow , проект PHD которые за очень короткое время приобрели значительную популярность. Его автор закончил обучение, а затем занялся карьерой, оставив очень мало времени для работы с файловой системой. Из-за того, что Linux не входит в дерево, постоянно меняющиеся внутренние компоненты Linux между версиями требуют, чтобы любой, кто хочет использовать его в современном ядре, обладал глубокими знаниями, которыми обладают немногие.

Если бы он использовал FUSE API, его было бы намного проще поддерживать, и фактическая работа по преобразованию ext3 в копию файловой системы при записи получила бы больше внимания. Это также относится к коду в ядре, который собирает плесень, потому что никому не хватает смелости (или достаточно скучно), чтобы прикоснуться к нему.

Файловые системы пользовательского пространства легче отлаживать

В пользовательском пространстве у вас есть потрясающие инструменты, такие как Valgrind (и его друзья, такие как massif), которые являются бесценными и простыми в использовании инструментами. Кривая обучения, связанная с отладкой ядра, часто слишком велика для многих людей, чтобы просто вмешаться и написать код.Обратите внимание: я четко разделяю архитектуру FUSE и микроядра, как отмечено в этом ответе . Некоторые системы на основе микроядра чрезвычайно сложно отлаживать, в основном из-за различий в обмене данными между запущенными службами (vfs, блочное устройство, файловая система, ipc). В обоих случаях код легче отлаживать, потому что он выходит из ядра, при условии, что он находится вне ядра, не привносит странных сложностей.

В любом случае, я возьму GDB и Valgrind за шумную printk () отладку в любой день или пытаюсь разобраться в довольно загадочных крючках отладки ядра, которые присутствуют в Linux. Мне также понравится возможность использовать любую реализацию отладки (или даже сборку мусора ) malloc () , которую я выберу. То же самое и с моей выбранной библиотекой C, при условии, что она работает с FUSE. Я не отказываюсь от библиотеки ядра Linux, но мне нравятся мои удобства.

Файловые системы в пользовательском пространстве проще использовать

Это большое преимущество для пользователей с ограниченными правами - возможность монтировать и поддерживать любую файловую систему, которую они хотят использовать, но на самом деле это конец игры. Если ваша файловая система находится вне ядра, она может развиваться независимо от ядра, что означает, что пользователи могут обновиться до вашего цикла выпуска . Можно предположить, что вы можете достичь 6 этапных выпусков за время, необходимое Linux, чтобы перейти к следующему выпуску-кандидату.Это также позволяет дистрибутивам и OEM-производителям выпускать вашу ФС в открытый доступ, где она получает необходимое тестирование быстрее, чем если бы это был модуль ядра.

Норман Рэмси уже описал фактор надежности, связанный с файловыми системами как услугой в архитектуре микроядра. Однако надежность означает отсутствие необходимости службы реинкарнации, которая имеет тенденцию скрывать (или откладывать) ошибки и другие проблемы. Я согласен с тем, что это хорошо, если неудачное монтирование root не приводит к прерыванию ядра, но это возможно и с монолитными ядрами с включенным FUSE.

Таким образом, написать файловую систему достаточно сложно без необходимости иметь дело с запуском в пространстве ядра. Я бы предпочел использовать FUSE API или изучить реализацию службы IPC / VFS в ОС на базе микроядра, чем писать ее как модуль ядра.

Код ядра должен соответствовать гораздо более высокому стандарту безопасности и защиты (т.е. без ошибок), чем код пользовательского режима.

В пользовательском пространстве у вас гораздо больше возможностей, поэтому разрабатывать программы проще. А если файловая система находится в пользовательском пространстве, то гораздо труднее из-за сбоя в файловой системе вывести из строя все ядро".

Этот принцип был доведен до крайности в таких проектах, как Mach и Windows NT, в которых система была разработана с микроядром, а как можно больше служб было вынесено в пользовательское пространство.