Станислав писал(а):
Если в итоге результатом труда будет драйвер в каком то формате и мне вроде будет легче его портировать, чем самому писать, то это офтоп(такое уже есть и ни кому не надо
Что именно есть и кому "никому" не надо? Единого бинарного стандарта нет.
Станислав писал(а):
а для сетевух вообще можно открытый формат взять с уже реализованными дровами для всех моделей
Да ничего подобного! Если ты говоришь про модель OSI, то это всего лишь концепция. Если ты говоришь про "дёрнуть исходники из Линукса", то это всего лишь "дёрнуть исходники из Линукса" с серьёзной адаптацией под свою ОСь, к тому же в моём случае перенести из монолита в микроядро. Где ты видел готовые кроссплатформенные бинарные драйвера для сетевух?
Станислав писал(а):
Заняться работой просто нужно, причём работой по разработке, разбору алгоритмов, спеков, набить любой алгоритм все могут.
Как раз этим должны заниматься производители железа. А глобальная идея состоит в том, чтобы создать универсальный бинарный интерфейс, который позволял бы производителям делать драйвер для всех ОС сразу.
shm писал(а):
микроядерную архитектуру я детально не исследовал, поэтому я сам не смогу предложить эффективной модели. Меня тут немного настораживает только тот факт, что клиент-серверные драйверы менее эффективны, хотя многие сторонники опровергают это. Если хочешь развития этой темы, то предлагай свои идей. Прежде всего меня интересует твое видение обобщенная модели обмена ядро-драйвер-устройтво.
Конечно, теоретически микроядерная архитектура не может быть быстрей монолита. Однако, моё мнение таково, что можно сделать микроядерную модель, почти не уступающую в производительности монолиту. К сожалению, я пока не располагаю фактической доказательной базой, но есть некоторые умозрительные заключения. Вот моя концепция.
У драйвера следующие функции. Я пока не буду рассматривать сервисы, в т.ч. то, что называют драйверами файловых систем, т.к. эти функции намного более ОС-специфичны и о них речь не идёт. Наша задача - поддержание работы устройств. Так вот, функции...
1. Управляющее воздействие на устройство по команде ОС.
2. Проверка состояния устройства по запросу.
3. Реакция на изменение состояния устройства.
Всё остальное должно быть вынесено из драйвера, включая проверку прав доступа к железу, как не имеющее непосредственного отношения к конкретному классу устройств, а более близкое специфике ОС. На производителя драйвера нельзя возлагать никаких других задачь, кроме указанных.
Начну с рассмотрения вопроса унификации микроядро/монолит.
1. Очевидно, код должен быть релокируемым. Т.е. это должен быть или исполняемый бинарник с поддержкой таблицы релокаций или объектный файл в одном из лицензионно свободных форматов. Это требование никак не влияет на производительность драйвера.
2. В коде не должно быть никаких привилегированных инструкций. В принципе, это требование также легко удовлетворить и непосредственно на производительность оно также не влияет.
3. Обмен событиями производится через прямые вызовы функций драйвера (во всех трёх типах) и через коллбэки (3-й тип). Влияние этого пункта на производительность ничтожно. Фактические дополнительные накладные расходытолько на косвенные вызовы функций из таблицы коллбэков вместо прямых для сообщений ОС об изменении состояния устройства. Но о разнице в данном случае даже смешно говорить.
4. Обмен данными производится через разделяемую память.
Собственно, при выполнении этих требований драйвер становится одинаково пригодным и для микроядра и для монолита, причём в случае монолита его производительность не страдает.
Почему я считаю, что производительность микроядра может приблизиться к монолиту? Причина следующая. Вся фактическая разница между двумя архитектурами сводится к переключению контекста в случае микроядра. Т.е. тормоза происходят в момент возникновения одного из трёх указанных пунктов. Однако в большинстве случаев любое изменение и так достаточно затратно, т.к. драйвер должен принять и проверить входные данные и подготовить выходные. По этой причине все усилия разработчиков как правило направлены на минимизацию количества этих переключений. Поэтому, например, никто не рисует попиксельно в видеопамяти, а либо вызывает соответствующую глобальную функцию отрисовки в драйвере, либо рисует в памяти и вызывает функцию копирования. В целом получается быстрей постоянных переключений/вызовов. Прямые дополнительные расходы в микроядре получаются - несколько ассемблерных инструкций для смены контекста и расходы на перезагрузку CR3 (смена виртуального адресного пространства). Перезагрузка CR3, уже считали, приводит к потере производительности в доли процента. Потери на смену контекста будут зависеть от количества вызовов в единицу времени, но как я уже отметил, всеобщая тенденция направлена на их минимизацию потому что эти вызовы и без того трудозатратны.
Ещё я считаю, что нужно рассмотреть следующий вопрос: возможность гибридизации даже в рамках драйвера. Т.е. наиболее критические участки, - реакция на прерывания, - могут выполняться в контексте ядра, а остальное (включая отложенные прерывания) в своём адресном пространстве. Для этого надо разделить и код, и данные на две независимые секции, так чтобы код и общие данные (например, мьютексы) первичной обработки прерывания можно было разместить в общем адресном пространстве. Такая архитектура может увеличить производительность при незначительной потере надёжности. Более того, в принципе, можно сделать
настраиваемую архитектуру, когда пользователь выбирает сам, чем жертвовать, надёжностью, скоростью или выбрать оптимальный компромисс!
Но это всё фигня. Это только самый базовый уровень. А ведь каждый класс устройств должен иметь свой набор вызовов и коллбэков и в их составлении бОльшая часть работы.