OSDev

Для базовых функций ядра достаточно использовать фиксированные номера, т.к. без этих функций ядро все равно не сможет нормально выполнять свою работу, хотя условно их тоже можно разделить на отдельные группы. Что касается подключаемых сервисных функций, то у меня есть три категории: серверные функции, функции виртуальных устройств (VDS) и функции управляющих структур (CSS). Серверные функции регистрируются по номеру и обращение к ним происходит по этому же фиксированному номеру (изначально они вешались исключительно на int'ы, но сейчас для обращения к ним есть специальная функция ядра - при регистрации нужно указать способ подключения). VDS и CSS регистрируются по имени и по типу, а обращение идет по описателю. CSS обычно предоставляют внутренний интерфейс подсистемам ядра для управления устройствами определенного типа, которые они же и захватывают в процессе монтирования. Например, драйвер для FAT32 через управляющую структуру "FAT32" типа FS предоставляет интерфейс для VFS, которая является подсистемой ядра. Когда VFS обращается к устройству, она использует именно функции захватившей его управляющей структуры, а не функции самого устройства. Если устройство остается свободным, к нему возможно обращение со стороны любого caller'а по описателю и номеру функции, причем номера функций 0-15 накладываются на номера системных функций DeviceIO0-15.

Модули ядра могут обращаться к системному сервису не только через единую точку входа, но и через индивидуальные таблицы, в которых импорт также выполняется по номеру, т.е. номера заменяются на адреса.

Есть три способа реализации точки входа: через шлюз вызова, через шлюз прерывания/ловушки и через syscall/sysenter. Можно одновременно реализовать несколько способов.

SII, между модулями самого ядра. Понятно, а про WDM можно подробнее? Или ссылку на максимально краткое описание? Там по сути через импорт функций ntoskrnl? А допустим файловые системы - это что нибудь типа vfat.dll, к которому подключаются все драйвера файловых систем?

Yoda, то что ты пишешь мне на 100% понятно, спасибо. Просто это не особо подходит как мне кажется при динамической модели, когда состав модулей может быстро меняться. В частности, сложно вести таблицу констант API_call_N, из-за неё возникнет путаница, тем более я больше склоняюсь к адресации по именам.

phantom-84, понятно. А если убрать разделение на сервисные функции, CSS и VDS, что останется в сухом остатке? Про организацию точки входа мне известно.

Пойми. Такого ещё никто не придумал.

Максимум. что есть одинаковый интерфейс. Набор функций и процедур который оговорен описан.
Вызов таких функций идет через указатель на функцию. Модуль загружается прописывает в указатели ссылки на свои функции.
А программы которые должны взаимодействовать вызывают через эти функции.
Так как функционал уже оговорен то оно получается фиксированным. Получается что набор функций заранее известен.

Просто заранее известны имена подпрограмм ядра, которые могут вызываться драйверами (в т.ч. файловыми системами), и чётко прописаны соглашения о связях, параметры и т.д. Соответственно, реализация подсистем ядра может меняться как угодно, но драйверы будут нормально работать -- поскольку интерфейс между драйверами и ядром не меняется. И наоборот, можно менять драйверы, но всё будет нормально работать.

То же самое можно распространить на всю систему в целом (собственно, и распространяется, просто документация не открывается). Например, можно полностью переписать менеджер памяти, но, если соблюсти все заранее описанные соглашения о связях (подпрограммы менеджера, доступные другим модулям), то всё остальное будет с ним нормально работать и дальше.

Технически используются команды CALL, естественно: переключение режимов процессора не требуется, поскольку весь код находится в ядре, поэтому такие вызовы являются самыми оптимальными. Если надо реализовать часть системы в пространстве пользователя, там надо придумывать иной метод, который в общем случае сводится к INT.

Не нужно путать системные функции (обязательные) и библиотечные функции. Системные функции вполне успешно могут настраиваться по номерам, если для них предусмотрено использование постоянных номеров. Настройка по именам используется для обобщения механизма обращения к системным и библиотечным функциям внутри пространства ядра. В линухе используются динамически компонуемые с ядром модули, а в винде библиотеки ядра.

Естественно, системные функции ядра.

Тащемта я всё для себя решил, спасибо за обсуждение!

зручит как какое то оружие, типо ядерной боеголовки.