OSDev

для всех
Текущее время: 19 окт 2019, 04:46

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 44 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
 Заголовок сообщения: Re: Идея универсальный драйверов
СообщениеДобавлено: 08 ноя 2012, 15:30 
Аватара пользователя

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Идея универсальный драйверов
СообщениеДобавлено: 08 ноя 2012, 15:40 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 963
Откуда: Дагоба
pavia писал(а):
способ передачи через функцию не означает что данные передаются копированием. Они могут передоваться по ссылке.

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

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

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

SII писал(а):
1) Если требуется одно лишнее переключение контекста -- да, таковым можно пренебречь (будет медленней, но общая разница слишком мала). Однако нередко требуется пропустить запрос ввода-вывода через целый стек драйверов.

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

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

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

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

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

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

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Идея универсальный драйверов
СообщениеДобавлено: 08 ноя 2012, 15:59 
Аватара пользователя

Зарегистрирован: 14 май 2012, 22:17
Сообщения: 99
Yoda писал(а):
4. Обмен данными производится через разделяемую память.
Собственно, при выполнении этих требований драйвер становится одинаково пригодным и для микроядра и для монолита, причём в случае монолита его производительность не страдает.
Почему я считаю, что производительность микроядра может приблизиться к монолиту? Причина следующая. Вся фактическая разница между двумя архитектурами сводится к переключению контекста в случае микроядра. Т.е. тормоза происходят в момент возникновения одного из трёх указанных пунктов. Однако в большинстве случаев любое изменение и так достаточно затратно, т.к. драйвер должен принять и проверить входные данные и подготовить выходные. По этой причине все усилия разработчиков как правило направлены на минимизацию количества этих переключений. Поэтому, например, никто не рисует попиксельно в видеопамяти, а либо вызывает соответствующую глобальную функцию отрисовки в драйвере, либо рисует в памяти и вызывает функцию копирования. В целом получается быстрей постоянных переключений/вызовов. Прямые дополнительные расходы в микроядре получаются - несколько ассемблерных инструкций для смены контекста и расходы на перезагрузку CR3 (смена виртуального адресного пространства). Перезагрузка CR3, уже считали, приводит к потере производительности в доли процента. Потери на смену контекста будут зависеть от количества вызовов в единицу времени, но как я уже отметил, всеобщая тенденция направлена на их минимизацию потому что эти вызовы и без того трудозатратны.


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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Идея универсальный драйверов
СообщениеДобавлено: 08 ноя 2012, 22:33 

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

pavia писал(а):
Но с нуля писать драйвер HDD не собираюсь.

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

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

Yoda писал(а):
Обмен событиями производится через прямые вызовы функций драйвера (во всех трёх типах) и через коллбэки (3-й тип)

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

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

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

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

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

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

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


Последний раз редактировалось shm 09 ноя 2012, 11:47, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Идея универсальный драйверов
СообщениеДобавлено: 09 ноя 2012, 00:00 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1389
Yoda писал(а):
SII писал(а):
Не всегда достижимо: для драйверов древнего оборудования необходимы IN и OUT.

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


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

Цитата:
SII писал(а):
1) Если требуется одно лишнее переключение контекста -- да, таковым можно пренебречь (будет медленней, но общая разница слишком мала). Однако нередко требуется пропустить запрос ввода-вывода через целый стек драйверов.

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


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

Цитата:
По этой причине всё пикоядро...


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

Цитата:
То есть, да, потери есть, но всё же их масштаб обычно преувеличивают


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

Цитата:
И надеяться я как раз могу :).


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Идея универсальный драйверов
СообщениеДобавлено: 09 ноя 2012, 02:53 
Заблокирован

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Идея универсальный драйверов
СообщениеДобавлено: 09 ноя 2012, 11:24 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1113
Меня больше устроит клиент-серверная. Так как хочу микро ядро попробовать. Гибрид тоже устроит, так как на данный момент система гибридная.

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Идея универсальный драйверов
СообщениеДобавлено: 09 ноя 2012, 11:49 

Зарегистрирован: 11 янв 2011, 22:17
Сообщения: 21
Станислав писал(а):
Я думал ты скажеш обработка ошибок, как ты это часто говориш.

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


Последний раз редактировалось shm 09 ноя 2012, 11:59, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Идея универсальный драйверов
СообщениеДобавлено: 09 ноя 2012, 11:51 

Зарегистрирован: 11 янв 2011, 22:17
Сообщения: 21
Станислав писал(а):
ACPI нужна не для драйвера

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Идея универсальный драйверов
СообщениеДобавлено: 09 ноя 2012, 11:58 

Зарегистрирован: 11 янв 2011, 22:17
Сообщения: 21
pavia писал(а):
С прерываниями пришлось извращаться для защиты системы от кривых драйверов.

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 44 ]  На страницу Пред.  1, 2, 3, 4, 5  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB