OSDev

В NetBSD есть развитые функции передачи страниц от процесса к процессу и ядру. Аналогичные функции есть и в Solaris (собственно оттуда многие идеи в NetBSD и перешли) и возможно ещё где-нибудь. ИМХО для блочных устройств такой способ идеален (драйвер запрашивает страницы, заполняет данными, например, с диска и передает инициатору запроса или наоборот - получает страницы с данными), собственно для этого этот механизм и был придуман. Надо только это как-то формальзовать для общего случая. Ну и естественно начать надо с классификации - блочное, символьное или ещё как-нибудь...

Про NetBSD почитать здесь: http://static.usenix.org/event/usenix99/full_papers/cranor/cranor.pdf

Передача данных по ссылке означает совместный доступ к области данных, на которые эта ссылка указывает. Это автоматически означает или жертву надёжности или выделение shared memory для этих данных, что полностью эквивалентно описанной мной модели. Или копирование .


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


Я понял твою мысль. Операция файлового ввода/вывода должна сначала пройти проверку прав доступа, затем пройти через драйвер файловой системы, затем через очередь (или кэш) операций блочного I/O и только затем попасть в драйвер устройства. Как я уже писал ранее, давай в данном контексте под драйвером понимать драйвер именно железки. В конце концов, промежуточные уровни (назовём их сервисами, хотя, конечно, в общем случае это не всегда так) можно интегрировать в ядро при относительно низкой потере надёжности. Их немного и с ними проще работать. Я говорю про выделение в отдельное пространство части аппаратного драйвера. В таком случае производительность пострадает не сильно.


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


Я сразу оговорился, что фактического материала у меня пока нет, есть пока умозрительные заключения. И надеяться я как раз могу .

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

Самая большая проблема "классического" микроядра - не только переключение контекстов но и передача данных между ними: ядром получен запрос на чтение файла (1) передаем запрос менеджеру безопасности - проверка прав доступа (2) менеджер безопасности возвращает права (3) передаём запрос подсистеме ввода-вывода - надо определить что за устройство и направить туда запрос (4) IO запрашивает менеджер кэша - возможно данные уже в памяти (5) неудачно - передаем запрос драйверу файловой системы (6) запрос драйверу диска (7) данные считаны и передаются драйверу файловой системы (8) драйвер файловой системы передает данные IO (9) IO уведомляет менеджер кэша что в памяти есть такие данные (10) IO возвращает данные ядру (11) ядро отдает данные в пользовательский процесс. Это совершенно навскидку, наверно что-то ещё забыл, например - надо получать страницы и т.п. В монолитных системах это простые вызовы процедур без передачи данных между пространствами а в микроядре мы вынуждены постоянно передавать данные (например - 8-16 страниц), да ещё и манипулировать с правами на эти данные. Понятно, что без хитростей не обходится, но радикально от недостатка избавится нельзя. Ещё одна засада - когда отдельное адресное пространство для ОС и задач - опять усложнение за счёт того, что ОС не может напрямую манипулировать данными в пользовательском пространстве - надо отображать.

Хотя сам я тоже думаю о том, что микроядро перспективнее...

Нафлудили...
Станислав, завязывай оффтопить, если нечего сказать по делу. Передо мной сейчас стоят два ПК и на все их потроха можно без проблем найти официальные маны (коме видеокарточек). лучше все равно не напишешь. Ты хочешь наклепать кучу непродуманных и недоделанных драйверов, это не серьезно. Лучше пусть у тебя будет 1 драйвер вместо 10ти, но реально продуманный, законченный и отлаженный.


Ну во-первых тебя никто и не заставляет. Во-вторых, если даже и хочешь его унифицировать, то непонятно зачем все переписывать. ИМХО реально достаточно будет ограничиться некоторыми обертками и небольшими допилами.

Почитал твою обработку прерываний... как то ты мутно описал. Все равно в конце концов у тебя будет вызван нужный обработчик прерывания, что собственно и нужно.


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


Это на самом деле мелочи, при большом желании их тоже можно отобразить на память к примеру.


Ну как минимум нужны еще функции управления кэшем и желательно хоть какой-нить уровень поддержи ACPI.

Короче я изучил мнения людей, в связи с чем предлагаю три варианта:
1. Клиент-серверная модель.
2. Гибридная.
3. Модуль пространства ядра.

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

А в 64-разрядном режиме это работает? (Я уже давно отошёл от IA-32, а посему многого не помню -- особенно того, с чем плотно работать не приходилось).



Как ни называй, смысл от этого не меняется. Вероятность наличия ошибок в большой и сложной программе (драйвере файловой системы, к примеру -- или, если угодно, в сервисе ) обычно всё же существенно выше, чем в маленькой и довольно простой (драйвере контроллера дисков). Так что с точки зрения надёжности логичнее как раз большие и сложные куски вытаскивать из ядра, а не наоборот -- тем более, что подобные куски как раз и не нуждаются в привилегированных операциях, поскольку им не нужен доступ к самому железу, а вот драйверам железа нужен. (Кстати, именно так сделано в графической подсистеме Вислы и Винды 7: в ядре оставлен лишь сравнительно небольшой и простой драйвер, прямо работающий с видюхой, а более высокоуровневые компоненты, включая компилятор шейдеров, вынесены в пространство пользователя). Кроме того, этих самых промежуточных уровней может быть достаточно много, а сами они могут меняться (например, появляются новые файловые системы); соответственно, просто так интегрировать их в ядро нельзя. Что же до надёжности, то сама по себе она не зависит от архитектуры системы, и это мы, кажется, уже обсуждали (и каждый остался при своём мнении, как обычно ).



Которое и должно было бы называться микроядром, а не монстры типа QNX Вот она, инфляция терминологии



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



Ну хорошо, хорошо. Надеяться можно, но рассчитывать -- нельзя

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


Я думал ты скажеш обработка ошибок, как ты это часто говориш.
ACPI нужна не для драйвера, а для системы. Должна быть система работающая и хорошо описанная работа в ней, а потом уже драйвера для неё.
Драйвер это только работа в регистрах контроллера и выделенном буфере памяти для него, а прерывания проверяют биты устройства и будят объекты запросившие данные с устройства и всё.

Меня больше устроит клиент-серверная. Так как хочу микро ядро попробовать. Гибрид тоже устроит, так как на данный момент система гибридная.

С прерываниями пришлось извращаться для защиты системы от кривых драйверов. Драйвера и ядро планирую вынести в 1 кольцо. Это особенность х86. В х86-64 нормально моюно разместить в 0.

Вы ещё незнаете что я со страницами напридумывал.

Станислав недавно в осдеве и поэтому горяч. Драйвер написать легко. А вот написать такой что бы неглючил и работал с любой железкой очень непросто. Вот хочешь ты показать ОС своему другу а у него видеокарта не дружит с веса и начинает вывод первой точки с середины монитора и вместо 1 жёсткого детектится 2 !!! ( из личной практики)

Это само собой разумеющиеся вещи.

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

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