OSDev http://osdev.su/ |
|
переносимые драйвера http://osdev.su/viewtopic.php?f=8&t=3905 |
Страница 1 из 1 |
Автор: | dzavalishin [ 28 ноя 2019, 15:45 ] |
Заголовок сообщения: | переносимые драйвера |
Коллеги. Множество людей в мире ведёт разработку тех или иных ОС. Всем нам нужны драйвера. Драйвера не так сильно зависят от архитектуры самой системы и вполне могут быть написаны в переносимом ключе. Я задумался над этим и сделал спецификацию переносимого драйвера. Если хотя бы несколько ОС договорятся её поддерживать и получится подготовить несколько драйверов для неё, то это облегчит жизнь всем альтернативным ОС. Посмотрите, пожалуйста. Особенно прошу посмотреть тех, кто имел реальный опыт переноса драйверов из системы в систему. Вот спека (англ) - https://openpod.readthedocs.io/en/latest/# Вот код: https://github.com/dzavalishin/openpod (код примерный, это всё ещё не проходило отладку и даже в Фантом не вставлено) Вот сюда можно и нужно оставлять комментарии: https://github.com/dzavalishin/openpod/issues Если захочется напечатать и посидеть с карандашом, то https://buildmedia.readthedocs.org/medi ... penpod.pdf Надо как-то начинать объединять усилия. |
Автор: | pavia [ 29 ноя 2019, 10:20 ] |
Заголовок сообщения: | Re: переносимые драйвера |
30 модулей ради 2-х функций? Это перебор. Драйвер это реализация API, не важно что он работает на сообщениях или ещё как. Так вот если вы хотите переносимыми драйвера вам нужно сделать 2 файла. 1. Файл *.h с API которое реализует драйвер. 2 Файл *.h с тем API которые он использует. Файл с документацией. И единый способ установки и размножения под однородные устройства. |
Автор: | dzavalishin [ 29 ноя 2019, 18:11 ] |
Заголовок сообщения: | Re: переносимые драйвера |
К сожалению, всё не так просто. 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 - второй. |
Автор: | pavia [ 29 ноя 2019, 19:32 ] |
Заголовок сообщения: | Re: переносимые драйвера |
dzavalishin писал(а): Конечно, всё это можно запихать в два .h файла, но кому от этого будет легче? Но, вообще, openpod.h - это первый, pod_kernel_api.h - второй. Всем легче. Основной мой посыл в том что-бы упростить. У вас через чур запутанная система. Если за 5 минут в ней нельзя с ориентироваться, то никто её даже рассматривать не будет. Мне проще взять uIP и FatLib там всё четко и понятно. Даже в исходниках просто ориентироваться. Берем u-boot тут шел, там специфичные вещи для чипа и тд. А у вас открываешь я ничерта не понятно. Сейчас я говорю о модульности и иерархичности проекта. Имена модулей согласно книги качественный код должны состоять из 1 слова. Если у вас они из 3-х, то что-о тут не не так, неправильно. Цитата: 4. Нужны варианты API устройства для разных типов. У сетевого драйвера есть get mac address, а у видео - bitblt. Возьмите ultibo там практически для всего есть интерфейс https://github.com/ultibohub/Core/blob/ ... buffer.pas Цитата: 3. Нужны процедуры передачи драйвером найденных устройств от драйвера к ядру. Драйвер может порождать несколько устройств, иногда - разного типа. Linux без этого обходится. Каждый программист может написать kmesg. А другой которому нужно распарсить и вызывать скрипт установки нужного драйвера mydriver -setup usb1.1 Цитата: 2. Нужны процедуры запуска и останова драйвера. Останова ещё ладно, его мало кто реально делает, но запуск - да. В С++ это main() это все знают. Шучу, но в каждой шутке есть доля шутки. Я бы взял что-то стандартное к примерку как это сделано в миникс. http://minix3.ru/docs/DriverProgramming-05.pdf Цитата: 1. Нужен набор сервисов со стороны ядра. В стандартном формате. malloc/interrupt/mutex/cond/mmap. Кстати, не все они ещё описаны в спецификации. Вроде в спецификации L4 я виде все. Цитата: 6. Эффективные драйвера (в частности - ahci и virtio) умеют ставить в очередь аппаратуре несколько запросов на ввод-вывод параллельно. Это значит, что точка входа в драйвер на запрос ввода-вывода не может быть синхронной, а должна иметь вид "запрос - мгновенный возврат - коллбек", а значит - нужно описать семантику работы с очередью. Чистым набором функций тут не обойтись. Нужно описание схемы работы, и там есть нетривиальные моменты, которые могут привести к race condition. А вам точно нужен обратный вызов? Я бы остановился на идеологии 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 |
Автор: | dzavalishin [ 29 ноя 2019, 21:11 ] |
Заголовок сообщения: | Re: переносимые драйвера |
Я в курсе, как бороться с race condition. Речь о том, что в спецификации на переносимые драйвера мало написать хедер файл. Нужно описать логику работы, которая не приведёт к race condition. Поллинг непригоден в реальной жизни. Реализация COW в виртуальной памяти без коллбеков не просто неэффективна, а смертельно неэффективна. |
Автор: | dzavalishin [ 29 ноя 2019, 21:18 ] |
Заголовок сообщения: | Re: переносимые драйвера |
А насчёт простоты - я подумаю. Действительно, наверное, сложновато с разбегу. Надо будет сделать примитивнейший пример кода... |
Страница 1 из 1 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |