OSDev

Готов разрабатывать систему с чистого листа (вернее с того, что уже мной наработано). Открыть новую тему?

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

Должна обеспечиваться поддержка стандартных файловых систем -- FAT-12 для дискет, FAT-32, NTFS, Ext для жёстких дисков и т.п. Понятное дело, что реализуется она по мере надобности. Свою же файловую систему изобретать стоит разве что в том случае, если ОС уже достаточно стабильно работает и имеет средства доступа к какой-либо стандартной файловой системе -- иначе замучаешься отлаживать одновременно ядро ОС, драйвера "железа" и поддержку собственной файловой системы.

Материалы? Часть файловых систем официально документирована, для некоторых (NTFS) информацию приходится разыскивать в различных источниках плюс добывать самому путём анализа содержимого дисков, изучения кода существующих систем и т.п. Поэтому опять-таки лучше начинать с поддержки тех файловых систем, устройство которых хорошо известно.

Руководствовался техническими требованиями. Перед этим в поисках разумной инфы прочёл книгу

Practical File System Design with the Be File System,
Dominic Giampaolo, Be, Inc.

и был немного разочарован тем, что не прочитал в ней ни одной новой идеи.

В некоторых случаях думаю имеет смысл начинать с родной ФС, так как ядро ОС может быть сильно ограничено существующими рамками ФС, что усложняет отладку.

А какая связь-то между ядром и ФС, чтобы последняя первое ограничивала, да ещё сильно?

SII
Ну, например, Unix на FAT -- это реально? Ведь тогда не будут проявлятся основные св-ва Unix по отношению к ФС.

если например ядро работает на графовой объектной структуре, где нужно сохранять объекты, их классы, возможно и методы классов, произвольные связи между объектами, то выбрав одну из существующих ФС придётся сильно ограничить возможности загрузки/сохранения объектов, или разрабатывать свой формат сохранения в файл на существующих ФС, что по сути эквивалентно разработке новой ФС.

vkos

Почему ж, вполне реально. Правда, FAT придётся малость дополнить, чтобы обеспечить все юниксовые возможности, однако обратная совместимость с ДОС сохранится (как, например, на дискете с файловой системой FAT-12 в Windows видны длинные имена файлов, а в ДОС -- только короткие). Естественно, полностью сохранится и система распределения места на диске. Ну а если плюнуть на юниксовскую специфику (назначение разных прав доступа к файлам и т.п.), то можно использовать вообще без доработки. В любом случае ядру на это глубоко наплевать -- это забота модуля, реализующего файловую систему (например, если ФС не поддерживает ограничение прав доступа, то соответствующие объекты будут считаться имеющими все виды доступа разрешёнными для всех пользователей).

SII

Да, но вместо дополнения FAT, проще написать свою ФС.

Конечно, на дополнительные возможности можно плевать, когда они не принципиальны. Но если они принципиально нужны ОС?
Тем более, что производительность на "своей" ФС всегда выше.

vkos

Объясните идиоту (т.е. мне :) ), как ФС может ограничивать возможности ядра? Желательно на примере :)

На примере - Unix.
Как Unix будет на FAT работать со ссылками?? Думаю никак...
Хотя это конечно не очень выразительный пример...

Так что лучше опишу какую-нибудь гипотетическую ОС.
У неё нет единой иерархической ФС. В ФС каждому файлу соответствует несколько путей, например:
home:///user/im
file:///usr/bin/gaim-1.5
userprog:///user/gaim
common:///progs/gaim

Кроме того, можно создавать свои категории:
myfavourite:///myim

Программы также смогут создавать свои категории.
Например, браузер создаст категорию http, https.
И через общую ФС можно будет обращаться к любым иинтернет-файлам.
А почтовая программа может создать категорию mailto...

И как такую ФС можно НОРМАЛЬНО реализовать в FAT??