OSDev

О чём именно идёт речь? Если в итоге результатом труда будет драйвер в каком то формате и мне вроде будет легче его портировать, чем самому писать, то это офтоп(такое уже есть и ни кому не надо, а для сетевух вообще можно открытый формат взять с уже реализованными дровами для всех моделей), если будет какой то код без объяснения, то такого тоже есть в линуксе, а если будет объяснение со спеками, то я по ним сам себе всё сделаю.
Заняться работой просто нужно, причём работой по разработке, разбору алгоритмов, спеков, набить любой алгоритм все могут.
Теоретический разбор дисков,системы прерываний, многопроцессорной системы, сетевой и проверка инициализация юсб2, и по мелочи я могу сделать в полном объёме, а ктонить другой сделает ещё чаго. Причём многие из вас могут сделать полный обзор всех стандартных файловых систем, чего нету в русскоязычном варианте.
Лучше договориться о том, как сделать обзор темы, чтобы по нему у каждого эта тема заработает. Причём это будет действительно стоящий труд, и его можно будет распечатать как книгу-пособие, или платный просмотр.
И вообще, ни чего нету лучше хорошего теоретического разбора. А чужого кода и готовых форматов полно, да труд большой и грамотный но лично мне абсолютно не нужный, хотя я бы многое отдал бы за то, чтоб это было у меня.

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

Бинарный формат у меня PE. Но для общего интерфейса надо будет и в эльфа компилировать.

По поводу прерываний. В отличии от большинства ОС у меня они могут прерываться.

Что значит "прерывания могут прерываться"? Если речь идет об отложенной обработке прерываний, то она есть в любой нормальной оси. А если о "тупом" наложении обработки прерываний друг на друга, то это грубейшая ошибка, которая чревата переполнением стека ядра.

[offtop]
Компьютер прерывается
- происходит смена контекста. Создается стека 0 ядра, далее стек прерывания.

Код обработчика прерывания.
-регистры сохраняются.
-номер прерывания заносится в "очередь сигналов".
-настраивается стек
-включаются прерывание

-Если очередь содержит 1 прерывание, то передается управление менеджеру прерываний.
-Если очередь содержит более 1 прерывание, то происходит возврат.


Менеджер перрывания.
- Находит потребителя(к примеру обработчик прерывания драйвер) и передает ему исполнение.
- если очередь не пуста то смотри предыдущий пункт
- если очередь пуста посылаем EOI выходим из контекста прерывания.


На функцию записи в очередь сигналов возложенна диагностика подсистемы прерываний.
PS. Детальнее к выходным если успею.
[/offtop]

Что именно есть и кому "никому" не надо? Единого бинарного стандарта нет.


Да ничего подобного! Если ты говоришь про модель OSI, то это всего лишь концепция. Если ты говоришь про "дёрнуть исходники из Линукса", то это всего лишь "дёрнуть исходники из Линукса" с серьёзной адаптацией под свою ОСь, к тому же в моём случае перенести из монолита в микроядро. Где ты видел готовые кроссплатформенные бинарные драйвера для сетевух?


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


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

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

Нет. Объмен надо в первую очередь вести через вызов функции такой как ioctl.
1. Разделяемая память не безопасна.
2. Разделяемая память не позволяет вмешатьс в процес передачи. Повесить фильтер или хук.
3. Единственный плюс это скорость передач. И в некоторых драйвера не обойтись.

Основным интерфейсом передачи надо делать через функцию и все драйверы должны это поддерживать. А вот через разделяемую память тоже надо, но не везде.

Причем если в "ioctl" ввести спецификацию указателя памяти. Чтение, запись, чтение+запись. То если использовать последний тип, то легко сделать разделяемую память.

В чём именно опасность?
А, понял, о чём ты. Нет, нужно не давать общий доступ к уже имеющейся странице памяти с какими-то данными, а заводить отдельные страницы специально предназначенные только для совместного использования. Впоследствии страницу можно "изъять" из общего доступа в монопольный доступ задаче или драйверу. Ещё можно делать "передаваемые" страницы, т.е. задача заполняет специально аллокированную страницу, затем отдаёт заполненную страницу драйверу и больше доступа к ней не имеет. Передаваемые страницы работают быстро, надёжно и безопасно. Там можно заводить структуры.


Нет, не мешает. Идёт заполнение памяти данными, а затем по окончании заполнения происходит вызов. Без вызова всё равно не узнаешь, готовы данные или нет. Здесь и вешай хуки.


Передача через функцию означает лишнее копирование данных со стека задачи в стек драйвера.

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

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

Не всегда достижимо: для драйверов древнего оборудования необходимы IN и OUT.



Два возражения.

1) Если требуется одно лишнее переключение контекста -- да, таковым можно пренебречь (будет медленней, но общая разница слишком мала). Однако нередко требуется пропустить запрос ввода-вывода через целый стек драйверов. Если каждый из них является задачей, то число этих переключений, вероятно, будет равно 2 * N против ровно 2 в системе, где все драйверы находятся в пространстве ядра. Здесь временем переключения контекста пренебречь уже, скорей всего, не удастся.

2) У разделяемой памяти есть одна проблема: для всех драйверов, участвующих в обработке данного запроса, должно быть произведено отображение какой-то части их виртуального адресного пространства на страницы, где физически находится необходимая область данных (скажем, на буфер ввода-вывода, заданный пользовательской задачей). Эта операция может быть довольно затратной, ведь надо корректировать таблицы переадресации и частично перезагружать TLB. Если же драйвер не один, а несколько, затраты умножаются. В то же время для драйверов режима ядра этой проблемы нет вообще, поскольку все они имеют доступ ко всей физической памяти.

В общем, я бы не рискнул утверждать или надеяться, что накладные расходы в микроядерной ОС будут лишь незначительно выше, чем в системе с монолитной архитектурой.

Если кто то до этого дорастёт, то будет считать миллиарды, и не будет здесь сидеть, а мы здесь и делаем всё сами. А главное для нас, это алгоритмы, описания, и хорошо комментированный код.


Драйвер для HDD можно ограничить функцией идентификации, чтения секторов и запись секторов, а это просто.



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

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