OSDev

Значит опять наступили каникулы, опять разработка ОС.

Вопрос ставлю ребром: нужен минимальный универсальный ядерный API, чтобы даже менеджер памяти и даже планировщик пердоставляли свои сервисы через него.

Как я это вижу? Есть ядро, после инициализации себя оно инициализирует первичный набор встроенных модулей. В числе этих модулей и менеджер памяти и планировщик. Первичный набор модулей вкомпилирован в бинарник ядра (хотя это и не принципиально). Модули при инициализации выставляют свои функции на экспорт. Говоря "простым" языком, менеджер памяти, загружаясь, говорит ядру: я готов выполнять функцию "запросить страницу" и "освободить страницу". Также модуль планировщика предоставляет, например, функции "приостановить поток", "запустить поток". Ну в общем понятно. Ключевой особенностью этого всего является то, что список функций формируется динамически. Тоесть я не могу сделать int 21 ax=4405 и знать что там такая то функция такого то модуля. Прежде чем вызывать функции, я должен запросить их у ядра. Загрузка любого процесса будет таким образом начинаться с команд типа "ядро, дай мне адрес вызова функции для модуля 'менеджер памяти' и функции 'выделить память'".

Два самых сложных вопроса для меня на данный момент в этой концепции это:
1. Каким образом реализовать первичный гейт? через ассемблерную команду int? через таблицу импорта? или ещё как то?
2. Каким образом однозначно идентифицировать модули и их функции? По номерам? По именам? По каким нибудь прочим замысловатым UID?

Вопрос в том, есть ли где уже такие разработки? Есть ли у кого нибудь аналогичные идеи или решения по данному вопросу?

Слишком много вопросов.

Таблица импорта. Тогда можно будет скрыть. Тобишь в любой момент поменять низкоуровневый формат.


Человек должен идентифицировать по названию. А машине лучше в машинном представлении.
Что касается машины, то надо решить задачу обновления модулей. Должна быть двойная идентификация. Общая и версионная.
Номера хороши если они в пределах одной фирмы одного человека. Одного модуля. А вот когда у вас модуль то тут лучше цифровая подпись. В которую должен входить идентификатор разработчика. Который должен хранится в общеизвестном каталоге. Идентификатора который описывает область назначения модуля. И случайного идентификатора. UID тоже пригодится.

Вопрос на самом деле один. Просто много маленьких вопросов - это так сказать его грани.

Версии модулей, цифровые подписи и идентификаторы разработчика - это уже всё слишком сложно, мне нужно намного проще систему делать. Для человека само собой модуль будет символьное название иметь, например менеджер памяти MemManager.cpp. Вопрос как идентифицировать его внутри уже работающей системы. Ну допустим для базовых модулей можно номера поставить типа 0 - менеджер памяти, 1 - планировщик и т.п., но вопрос что делат с другими модулями? Например подсистемы fat32 может и не быть, как обязательного компонента.

Пусть есть программа А. Есть программа Б и есть программа С.
Если программа А умеет общаться с Б.
То она не обязана уметь общаться с С. Возможно ей это и не к чему.
Ты не сможешь отделить Б от А. Или А от Б. Система перестанет работать.
И ты не сможешь научить общаться А с любой программой.

Исключение из правил А является искусственным интелектом.

Есть менеджер памяти есть файловый менеджер. Есть менеджер процессов и планировщик. Никуда от них не деться.
И они все знают о своем существовании и существовании других.

Посмотри как сделан OpenGL с его расширениями.
Посмотри как сделан виндоус с его системой драйверов. Никуда от монолита недеться.
DirectShow тоже недалеко ушёл.



fat может и не быть но виртуальная файловвая система должна быть и все будут знать что она есть.
Если её нету значит и номера у ней нету и UID тоже нету.


Что такое интерфейс? Это набор подпрограмм и протоколов описанный и задокументированный.

На вопрос нередко проще ответить, если знать, для чего что-то там такое нужно. Возможно, правильное решение лежит вообще в иной плоскости, а не в той, в которой ищется ответ...

Я так понял, что на этом форуме принято первый ответ писать более-менее по существу, а потом начинается "ла-ла-ла" и вопрос забалтывается. Предложить цифровые подписи новичку -- толсто.


Абстрагировать нужно не сами модули, а классы модулей, учитывая, что модулей какого-то класса в систему может быть загружено больше одного, как в случае файловых систем. SDK VFS должен включать в себя и интерфейс типа IFileSystem, реализуемый впоследствии конкретным модулем, типа FAT32.dll.

Код, использующий модули, сможет получить от ядра этот IFileSystem и использовать его, не вникая в подробности реализации. Нужно лишь внести в IFileSystem все нужные методы, чтобы ничего не приходилось запрашивать в обход него. Иначе это уже не абстракция, а каша.

Когда модулей одного класса несколько, должна быть возможность их перечисления и запроса интерфейса у конкретного модуля с передачей ему контекста -- номера или UID.

Посмотри код любой программы, использующей загружаемые модули. Не обязательно ОС, а просто программы, типа Far или Miranda.

Для сохранения переносимости лучше делать таблицы вызовов и уже в них инкапсулировать конкретный механизм - INT, SYSCALL/SYSRET или SYSENTER/SYSEXIT, в зависимости от того, что поддерживается и что больше приглянулось.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Слишком сложно. Нужно ещё проще.

Для чего? API - для использовании в кач-ве клея между модулями.

Между модулями чего, самого ядра? Если они все выполняются в нулевом кольце и в общем адресном пространстве, то просто документировать вызовы, представляющие "взаимный интерес", да и всё. Собственно, что такое драйверная модель Винды (WDM)? Это, по сути, и есть ядерный API системы, предназначенный для драйверов. Аналогичным образом и в своей системе можно поступать.

Что именно сложно??

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>