Цитата:
Вот есть идея VFS. А в виндах и идеи-то толком нет
В винде изначально идея - юзер явно задает устройство и путь на нем. Как "C:\path\to\file". Или "COM1:" для ком-порта. При этом одно устройство, как я понимаю, может находиться на другом. Имеем четкое дерево устройств. Можем четко передавать IO запросы родительскому устройству.
Цитата:
действительно решения, за которыми какое-то проектирование и теория стоят.
Не сказал бы: наплодить рандомное дерево с кучей перекрестных ссылок и к половине рандомных узлов привязать рандомные драйвера - это не серьёзное проектирование и теория. Из-за VFS изредка даже всплывают зияющие дыры в безопасности, например когда оказывается, что node можно перемонтировать на систему и писать туда из-за того, что драйвер проверочку не сделал (хотя если уж делается VFS, то это дело системы, разве нет?). Пока писал драйвер для линуска на работе - обплевался этой "чудесно спроектированной" системой. А мне ведь от драйвера всего ничего надо было.
По сабжу. У меня сделано так:
1) ПО открывает файл по строке следующего вида: DevName:(//)path/to/file (// сейчас нет, но потом может добавлю, если не лень будет. Все же смысловой нагрузки он не несет).
2) Система вызывает драйвер устройства DevName по точке входа resolve. Драйвер должен преобразовать path/to/file в реальное имя. Например, если ФС не поддерживает разные регистры букв - перевести к общему регистру, если в пути есть ссылки (симлинки/ярлыки, лежащие на диске) - развернуть их и так далее. Допустим, драйвер вернул путь my/new/file.txt
3) Система преобразует DevName к ID-шнику устройства фиксированной длины (пусть это будет 0001) и создает/открывает серию файлов:
0001:my
0001:my/new
0001:my/new/file.txt
Эти файлы выстраиваются в дерево. Если файл в памяти был создан, он просто открывается. Если нет - вызывается функция драйвера по открытию/созданию объекта, туда передается "объект". При создании драйвер может в "объект" (который является универсальным системным типом) в предусмотренные user-defined поля записать любые значения. Эти значения гарантировано не будут изменены до удаления объекта (файла).
Есть хорошие задатки:
1) Благодаря явному заданию устройства в начале пути мы скрываем от юзера/по дерево устройств, и потому оно имеет вполне четкую структуру (ведь никакой юзер не запускает в него свои кривые ручки). Можно организовать стек драйверов с вызовом драйвера родительского устройства через стандартные функции IO, при этом не реализуя дополнительную логику внутри драйвера.
2) Система не просматривает и не открывает те файлы, к которым за сеанс работы не будет ни одного обращения (таких абсолютное большинство), не создает лишних узлов в дереве файлов.
Но есть проблема - как сделать перечисление доступных файлов. Пока особо не думал. Скорее всего это будет одной из опциональных фич конкретного драйвера, и она будет возвращать список путей или просто имя N-го файла в определенной директории. Хотя бы потому, что не для каждого устройства эта операция имеет смысл.