Разработка драйвера FAT

Тема в разделе "WASM.OS.DEVEL", создана пользователем Kriks87, 20 мар 2011.

  1. Kriks87

    Kriks87 New Member

    Публикаций:
    0
    Регистрация:
    20 мар 2011
    Сообщения:
    1
    Всем доброго времени суток! Я новичок, поэтому заранее извиняюсь, если мой вопрос кому-то покажется глупым или ламерским. Имеется самописное ядро ОС, которое содержит менеджер памяти, умееть обрабатывать аппаратные и программные прерывания. Также данное ядро содержит драйвер IDE дисков, который предоставляет функции идентификации IDE дисков и чтения/записи сектора диска. Для этого ядра необходимо разработать драйвер для взаимодействия с файловыми системами (создание, запись, чтение файла, вывод списка файлов и т.д.). Для начала была взята файловая система FAT32 ввиду своей простоты. Одним словом, мне необходимо реализовать простейшие функции для работы с FAT32, предоставляемые данным ядром. Подскажите, каким образом должно осуществляться взаимодействие разрабатываемого драйвера FAT32 с драйвером IDE диска, к примеру, при реализации функции создания файла? Подскажите, существуют ли какие-то готовые решения драйверов FAT32 с открытыми исходниками или может быть кто-то уже занимался подобной проблемой? Подскажите также, какие статьи/книги можно почитать для прояснения данной задачи. Всем большое спасибо!
     
  2. ivan2k2

    ivan2k2 New Member

    Публикаций:
    0
    Регистрация:
    28 янв 2006
    Сообщения:
    95
    смотри исходники freedos, reactos, ...
     
  3. Phantom_84

    Phantom_84 New Member

    Публикаций:
    0
    Регистрация:
    6 июн 2007
    Сообщения:
    820
    Может, и никаким. Или можно проверить возможность создания файловой записи (наличие свободного пространства в случае расширения каталога, уникальность имени файла в пределах каталога), но пока ее не создавать, т.е. создать только в памяти. Вообще понятно, какие шаги нужно предпринять:
    - найти каталог по полному или относительному имени;
    - найти последний кластер каталога по FAT;
    - проверить достаточно ли места в кластере для добавления файловой записи;
    - если достаточно, то переписать кластер (частично или полностью);
    - если недостаточно, то найти свободный кластер, пометить его как последний в цепочке и "прицепить" его к предыдущему кластеру, после чего переписать данный кластер (при необходимости и предыдущий тоже);
    - обновить атрибуты текущего и всех вышележащих каталогов.
    Как-то так.

    Мне кажется основной источник вот этот: http://msdn.microsoft.com/en-us/windows/hardware/gg463080
     
  4. MisHel64

    MisHel64 Member

    Публикаций:
    0
    Регистрация:
    9 мар 2011
    Сообщения:
    182
    Господа!
    А кто видел описание 3го сектора BOOT сектора в FAT32?
    Что-то там есть, а вот что найти описание не удается.
     
  5. Phantom_84

    Phantom_84 New Member

    Публикаций:
    0
    Регистрация:
    6 июн 2007
    Сообщения:
    820
    Если можно, дамп в студию.
    Скорее всего это продолжение загрузочного кода, т.к. для FAT32 загрузочный код обычно пишется в объеме не более 1 Кб. Плюс FSInfo ("между кодом"). Получается 3 сектора, что подтверждается в различных источниках.

    FAT32 File System Spec.
    An Examination of the MSWIN4.1 OS Boot Record
     
  6. Pavia

    Pavia Well-Known Member

    Публикаций:
    0
    Регистрация:
    17 июн 2003
    Сообщения:
    2.409
    Адрес:
    Fryazino
    MisHel64
    А нету там ничего. Вернее к FAT они не относятся. Поэтому и помечены в нём как резервные.
    А загрузчик виндоуса его использует под свои нужды.
     
  7. Phantom_84

    Phantom_84 New Member

    Публикаций:
    0
    Регистрация:
    6 июн 2007
    Сообщения:
    820
    Спецификация все-таки определенным образом структурирует содержимое резервной области. Типичный пример - фактически жесткая привязка "резервной копии" к 7-му сектору. И хотя с одной стороны спецификация говорит о том, что "резервная копия" не является обязательной (по местоположению может совпадать с основной - BPB_BkBootSec=0), с другой стороны строго рекомендуется искать ее именно там, потому что по-другому никак (нельзя/невозможно использовать значение BPB_BkBootSec из основной копии, если с ней возникли какие-либо проблемы). Что еще интереснее, третий сектор спокойно может содержать FSInfo, о которой точно нельзя сказать, что она не относится к структуре файловой системы, т.к. является обязательной и содержит (помимо "мусора") весьма полезные поля. Причина размещать FSInfo именно в третьем секторе, а не во втором достаточно проста - желание разместить 1-килобайтовый загрузочный код в двух смежных секторах.
     
  8. MisHel64

    MisHel64 Member

    Публикаций:
    0
    Регистрация:
    9 мар 2011
    Сообщения:
    182
    Phantom_84: Ты не о том.
    Пример в аттаче.
     
  9. Phantom_84

    Phantom_84 New Member

    Публикаций:
    0
    Регистрация:
    6 июн 2007
    Сообщения:
    820
    Почему это я не о том? Теперь четко видно, что имеет место типичная для M$ структура загрузочной записи:
    первый сектор - загрузочный код;
    второй сектор - FSInfo;
    третий сектор - дополнительный (догружаемый) загрузочный код.

    А последнюю речь я выдал в ответ на слова Pavia и еще из-за того, что вполне возможна такая структура загрузочной записи:
    первый сектор - загрузочный код;
    второй сектор - дополнительный загрузочный код;
    третий сектор (разве не о нем вы спрашивали?!) - FSInfo.

    Поэтому нужен был дамп, причем сразу. Удачи.