OSDev

Коллеги.

Множество людей в мире ведёт разработку тех или иных ОС. Всем нам нужны драйвера. Драйвера не так сильно зависят от архитектуры самой системы и вполне могут быть написаны в переносимом ключе.

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

Посмотрите, пожалуйста. Особенно прошу посмотреть тех, кто имел реальный опыт переноса драйверов из системы в систему.

Вот спека (англ) - https://openpod.readthedocs.io/en/latest/#
Вот код: https://github.com/dzavalishin/openpod
(код примерный, это всё ещё не проходило отладку и даже в Фантом не вставлено)
Вот сюда можно и нужно оставлять комментарии: https://github.com/dzavalishin/openpod/issues

Если захочется напечатать и посидеть с карандашом, то https://buildmedia.readthedocs.org/medi ... penpod.pdf

Надо как-то начинать объединять усилия.

30 модулей ради 2-х функций? Это перебор.

Драйвер это реализация API, не важно что он работает на сообщениях или ещё как.

Так вот если вы хотите переносимыми драйвера вам нужно сделать 2 файла.
1. Файл *.h с API которое реализует драйвер.
2 Файл *.h с тем API которые он использует.
Файл с документацией. И единый способ установки и размножения под однородные устройства.

К сожалению, всё не так просто.

1. Нужен набор сервисов со стороны ядра. В стандартном формате. malloc/interrupt/mutex/cond/mmap. Кстати, не все они ещё описаны в спецификации.

2. Нужны процедуры запуска и останова драйвера. Останова ещё ладно, его мало кто реально делает, но запуск - да.

3. Нужны процедуры передачи драйвером найденных устройств от драйвера к ядру. Драйвер может порождать несколько устройств, иногда - разного типа.

4. Нужны варианты API устройства для разных типов. У сетевого драйвера есть get mac address, а у видео - bitblt.

5. Нужно определить, как драйвер получает доступ к конфигурационной информации от ядра. Минимум - как он получает конфигурацию PCI.

В принципе, на этом можно остановиться, но.

6. Эффективные драйвера (в частности - ahci и virtio) умеют ставить в очередь аппаратуре несколько запросов на ввод-вывод параллельно. Это значит, что точка входа в драйвер на запрос ввода-вывода не может быть синхронной, а должна иметь вид "запрос - мгновенный возврат - коллбек", а значит - нужно описать семантику работы с очередью. Чистым набором функций тут не обойтись. Нужно описание схемы работы, и там есть нетривиальные моменты, которые могут привести к race condition.

7. Эффективная работа пейджера с диском требует возможности отзывать сделанные запросы на ввод-вывод и менять им приоритет. Мало того, драйвер диска действительно должен учитывать приоритет запроса, иначе сильно проседает реактивность ОС под большой нагрузкой на ввод-вывод.
Это из практики. Значит, нужны операции для этого.

Конечно, всё это можно запихать в два .h файла, но кому от этого будет легче?

Но, вообще, openpod.h - это первый, pod_kernel_api.h - второй.

Всем легче. Основной мой посыл в том что-бы упростить. У вас через чур запутанная система. Если за 5 минут в ней нельзя с ориентироваться, то никто её даже рассматривать не будет.
Мне проще взять uIP и FatLib там всё четко и понятно. Даже в исходниках просто ориентироваться.
Берем u-boot тут шел, там специфичные вещи для чипа и тд. А у вас открываешь я ничерта не понятно. Сейчас я говорю о модульности и иерархичности проекта. Имена модулей согласно книги качественный код должны состоять из 1 слова. Если у вас они из 3-х, то что-о тут не не так, неправильно.



Возьмите ultibo там практически для всего есть интерфейс
https://github.com/ultibohub/Core/blob/ ... buffer.pas


Linux без этого обходится. Каждый программист может написать kmesg. А другой которому нужно распарсить и вызывать скрипт установки нужного драйвера mydriver -setup usb1.1


В С++ это main() это все знают. Шучу, но в каждой шутке есть доля шутки. Я бы взял что-то стандартное к примерку как это сделано в миникс.
http://minix3.ru/docs/DriverProgramming-05.pdf


Вроде в спецификации L4 я виде все.



А вам точно нужен обратный вызов? Я бы остановился на идеологии REST, правда там решается путем опроса(polling - полинг не путать с пулингом)

https://ru.wikipedia.org/wiki/REST
Или как в ПЛК, когда есть ячейка в неё пишем.

race condition - двойной lock (википедию не читаем там описано неправильно с ошибками). В теории СУБД race condition давно научились бороться припомощи спецификаторов которые описывают как обращаться к данным что-бы не было DedLock'ов.
Называются эти спецификаторы как "уровниметоды изоляции транзакций".
https://docs.microsoft.com/ru-ru/sql/t- ... s-pdw-2016
READ UNCOMMITTED
| READ COMMITTED
| REPEATABLE READ
| SNAPSHOT
| SERIALIZABLE
При помощи них можно описать как читать из очереди без блокировок. Хорошего описания у меня нету. В том смысле что-бы кратко и лаконично. Но я собрал все что касается этой темы, можно читать pdf они дублируют архив страниц.
https://yadi.sk/d/zeV90jnZHIN1cg

Я в курсе, как бороться с race condition. Речь о том, что в спецификации на переносимые драйвера мало написать хедер файл. Нужно описать логику работы, которая не приведёт к race condition.

Поллинг непригоден в реальной жизни. Реализация COW в виртуальной памяти без коллбеков не просто неэффективна, а смертельно неэффективна.

А насчёт простоты - я подумаю. Действительно, наверное, сложновато с разбегу.

Надо будет сделать примитивнейший пример кода...