Интерфейс драйвера

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

  1. abcd008

    abcd008 New Member

    Публикаций:
    0
    Регистрация:
    8 фев 2009
    Сообщения:
    616
    Пишу систему и возник вопрос про организацию драйвера.
    как драйвер должен взаимодействовать с ОС и наоборот?
    желательно сделать стандартный интерфейс для всех драйверов устройств?
    какие должны быть стандартные функции?
     
  2. Phantom_84

    Phantom_84 New Member

    Публикаций:
    0
    Регистрация:
    6 июн 2007
    Сообщения:
    820
    Можешь сделать как обычные файловые операции плюс IOCTL для расширений. Причем можно сделать как с автоматической блокировкой буферов ввода/вывода, так и без. Что касается взаимодействия драйверов с ядром, то это не слишком сложно сделать. Просто нужно каким-либо способом защитить этот способ взаимодействия с ядром от приложений.

    В интерфейсе драйверов устройств я использую только IOCTL-функции, причем без автоматической блокировки буферов ввода/вывода (драйверы сами блокируют буферы, обращаясь к ядру, если им это необходимо). Для облегчения написания драйверов устройств ядро не позволяет выполнять реентерабельные и циклические обращения к функциям устройств. Если драйвер выполняет одну функцию устройства, то все другие функции автоматически блокируются. Open/Close-механизм я не использую. Устройство должно само заботиться о правильном порядке обращения к его функциям. Однако можно сделать полностью монопольный доступ к устройству для отдельно взятого модуля, например, для драйвера конкретной ФС можно сделать монопольный доступ к устройствам хранения, на которых присутствует соответствующая ФС. Драйвер может зарегистрировать произвольное количество виртуальных устройств. Параллельно могут выполняться только функции, относящиеся к разным устройствам. Что касается обращения к ядру со стороны драйверов, то я использую два варианта. Первый - единая точка входа (номера прикладных функций начинаются с нуля и возрастают, а номера драйвер-специфичных функций начинаются с -1 и убывают). Второй - таблицы импорта в драйверах (номера используемых функций заменяются в таблице их адресами, после чего идет обращение к функциям по этим адресам). Драйвер может обращаться к прикладным функциям точно также, как это делают приложения, но только при условии, что он при этом использует прикладные буферы.
     
  3. abcd008

    abcd008 New Member

    Публикаций:
    0
    Регистрация:
    8 фев 2009
    Сообщения:
    616
    а ты свой формат файла делал или PE используешь?
    какие должны быть обязательные функции в драйвере?
     
  4. Phantom_84

    Phantom_84 New Member

    Публикаций:
    0
    Регистрация:
    6 июн 2007
    Сообщения:
    820
    Свой, но это не так важно.

    У меня в драйвере только одна обязательная функция - инициализация/деинициализация драйвера. Можешь сделать для устройства какую-нибудь обязательную информационную функцию. У меня общую информацию о зарегистрированных устройствах возвращает ядро. У каждого типа устройств свой стандартный интерфейс. Если у тебя ведущая роль при создании устройств будет отводиться ядру, то драйвер должен иметь стандартный интерфейс, обрабатывающий запросы ядра на создание/удаление и другие операции с устройствами, которые требуются твоей системе.
     
  5. abcd008

    abcd008 New Member

    Публикаций:
    0
    Регистрация:
    8 фев 2009
    Сообщения:
    616
    а у тебя как. если несколько подобных устройств то ты пользуешься одним драйвером или для каждого устройства свой?
    как надо. чтоб система нашла устройство, а потом искала драйвер? или драйвер должен проверить наличие устройства и подключиться в работу?

    и то и то верно. наверно сначало я ишу тип устройства. потом гружу драйвера этого типа, а они проверяют на совместимость.

    это я для устройств без vendor. там я понимаю проверил драва на соответствие вендора и загрузил


    блин похоже этот форум только для нас двоих)
     
  6. Phantom_84

    Phantom_84 New Member

    Публикаций:
    0
    Регистрация:
    6 июн 2007
    Сообщения:
    820
    Я уже писал об этом: "Драйвер может зарегистрировать произвольное количество виртуальных устройств." Причем устройства могут быть даже разного типа. В добавок драйвер может регистрировать не только устройства, но и другие объекты, например, файловые системы. Показательно, что модуль, загружаемый вместе с ядром, для работы с жесткого диска совмещает в себе собственно драйвер жесткого диска, менеджер томов и драйверы файловых систем FAT16 и FAT32 (в перспективе еще большего количества ФС). Драйвер жесткого диска регистрирует только устройства. Менеджер томов регистрирует управляющую структуру для блокировки "цельных устройств" и предоставления специального интерфейса, а также устройства, соответствующие найденным на дисках разделам. Каждый драйвер ФС регистрирует управляющую структуру типа "ФС" для блокировки устройств, на которых присутствует соответствующая ФС, и предоставления специального интерфейса для VFS.

    У меня драйверы сами проверяют свою востребованность (наличие вендор-специфичных устройств или просто устройств подходящего типа). Ограничить их активность можно следующими способами:
    1) просто их не загружать;
    2) загружать их не непосредственно ядром, а каким-нибудь автоконфигуратором, перечислителем устройств и т.п.;
    3) указать ограничения в строке параметров соответствующего драйвера;
    4) заблокировать системные ресурсы, требуемые для нормальной работы драйвера с устройствами (порты, линии прерываний и т.п.).

    Меня это не волнует))). А тебя?
     
  7. abcd008

    abcd008 New Member

    Публикаций:
    0
    Регистрация:
    8 фев 2009
    Сообщения:
    616
    -Меня это не волнует))). А тебя?
    блин просто много тем где мне даже не ответили. а народу здесь ого-го.


    буду думать. вся сложность что мне надо чтоб драйвер работал в нескольких режимах.
    до ос в реальном (например vesa edid)
    потом все что может сам в x64
    а то что не может, но есть поддержка биос 32 в x32
     
  8. Phantom_84

    Phantom_84 New Member

    Публикаций:
    0
    Регистрация:
    6 июн 2007
    Сообщения:
    820
    Думаю, в разных режимах лучше использовать разные драйверы и драйверные модели.
     
  9. abcd008

    abcd008 New Member

    Публикаций:
    0
    Регистрация:
    8 фев 2009
    Сообщения:
    616
    но как тогда они будут взаимодействовать.
    например узнать адрес входа в 32 vesa я могу только из RM
    пользоваться потом только в x32 режиме.
    ну а вывод изображения уже в родном x64
     
  10. Phantom_84

    Phantom_84 New Member

    Публикаций:
    0
    Регистрация:
    6 июн 2007
    Сообщения:
    820
    Забей на vesa))) Оставь только 64-разрядные драйверы.

    У меня все драйверы, которые хоть как-то связаны с реальным режимом, находятся непосредственно в ядре. Примеры: первичный видеодрайвер - проверка vga-совместимости в RM; PCI-драйвер - определение параметров и начало работы на шине в RM; пока что весьма примитивный ACPI-драйвер - детект и начальный разбор таблиц в RM; клавиатурный драйвер - его компоненты не работают в RM (работа с контроллером для открытия Gate A20 отделена от драйвера и относится к ядру, хотя конечно это все условно), однако он получает управление на стадии первичной инициализации в PM и использует состояние индикаторов из BDA по адресу 400h (идентичное отображение еще работает), хотя тот же самый участок памяти уже доступен по адресу KERNEL_BASE+400h (возможно, я буду убирать отображение BDA в пространстве ядра, поэтому даю управление клавиатурному драйверу во время первичной инициализации плюс он отображает на экране сообщение о своей готовности сразу после видеодрайвера, что вполне логично).