OSDev http://osdev.su/ |
|
Идея универсальный драйверов http://osdev.su/viewtopic.php?f=5&t=646 |
Страница 4 из 5 |
Автор: | D-S [ 08 ноя 2012, 15:30 ] |
Заголовок сообщения: | Re: Идея универсальный драйверов |
В NetBSD есть развитые функции передачи страниц от процесса к процессу и ядру. Аналогичные функции есть и в Solaris (собственно оттуда многие идеи в NetBSD и перешли) и возможно ещё где-нибудь. ИМХО для блочных устройств такой способ идеален (драйвер запрашивает страницы, заполняет данными, например, с диска и передает инициатору запроса или наоборот - получает страницы с данными), собственно для этого этот механизм и был придуман. Надо только это как-то формальзовать для общего случая. Ну и естественно начать надо с классификации - блочное, символьное или ещё как-нибудь... Про NetBSD почитать здесь: http://static.usenix.org/event/usenix99/full_papers/cranor/cranor.pdf |
Автор: | Yoda [ 08 ноя 2012, 15:40 ] |
Заголовок сообщения: | Re: Идея универсальный драйверов |
pavia писал(а): способ передачи через функцию не означает что данные передаются копированием. Они могут передоваться по ссылке. Передача данных по ссылке означает совместный доступ к области данных, на которые эта ссылка указывает. Это автоматически означает или жертву надёжности или выделение shared memory для этих данных, что полностью эквивалентно описанной мной модели. Или копирование . SII писал(а): Не всегда достижимо: для драйверов древнего оборудования необходимы IN и OUT. Согласен. Но для этого есть промежуточные кольца защиты, их и следует задействовать. SII писал(а): 1) Если требуется одно лишнее переключение контекста -- да, таковым можно пренебречь (будет медленней, но общая разница слишком мала). Однако нередко требуется пропустить запрос ввода-вывода через целый стек драйверов. Я понял твою мысль. Операция файлового ввода/вывода должна сначала пройти проверку прав доступа, затем пройти через драйвер файловой системы, затем через очередь (или кэш) операций блочного I/O и только затем попасть в драйвер устройства. Как я уже писал ранее, давай в данном контексте под драйвером понимать драйвер именно железки. В конце концов, промежуточные уровни (назовём их сервисами, хотя, конечно, в общем случае это не всегда так) можно интегрировать в ядро при относительно низкой потере надёжности. Их немного и с ними проще работать. Я говорю про выделение в отдельное пространство части аппаратного драйвера. В таком случае производительность пострадает не сильно. SII писал(а): 2) У разделяемой памяти есть одна проблема: для всех драйверов, участвующих в обработке данного запроса, должно быть произведено отображение какой-то части их виртуального адресного пространства на страницы, где физически находится необходимая область данных (скажем, на буфер ввода-вывода, заданный пользовательской задачей). Эта операция может быть довольно затратной, ведь надо корректировать таблицы переадресации и частично перезагружать TLB. Если же драйвер не один, а несколько, затраты умножаются. В то же время для драйверов режима ядра этой проблемы нет вообще, поскольку все они имеют доступ ко всей физической памяти. По этой причине всё пикоядро у меня написано на ассемблере. Я считаю, что наиболее частые и/или критичные по времени операции, такие как работа с виртуальной памятью, межпроцессное взаимодействие и первый уровень обработки прерываний, должны быть предельно оптимизированы. Сейчас у меня большинство операций с памятью, включая поиск свободной страницы, выделение, освобождение, мапирование, - это выполнение около одного-двух десятков ассемблерных инструкций, которые выполняются в пространстве задачи. А про перезагрузку TLB мы, по-моему, как раз и составляли калькуляцию в десятые доли процента. То есть, да, потери есть, но всё же их масштаб обычно преувеличивают. SII писал(а): В общем, я бы не рискнул утверждать или надеяться, что накладные расходы в микроядерной ОС будут лишь незначительно выше, чем в системе с монолитной архитектурой. Я сразу оговорился, что фактического материала у меня пока нет, есть пока умозрительные заключения. И надеяться я как раз могу . |
Автор: | D-S [ 08 ноя 2012, 15:59 ] |
Заголовок сообщения: | Re: Идея универсальный драйверов |
Yoda писал(а): 4. Обмен данными производится через разделяемую память. Собственно, при выполнении этих требований драйвер становится одинаково пригодным и для микроядра и для монолита, причём в случае монолита его производительность не страдает. Почему я считаю, что производительность микроядра может приблизиться к монолиту? Причина следующая. Вся фактическая разница между двумя архитектурами сводится к переключению контекста в случае микроядра. Т.е. тормоза происходят в момент возникновения одного из трёх указанных пунктов. Однако в большинстве случаев любое изменение и так достаточно затратно, т.к. драйвер должен принять и проверить входные данные и подготовить выходные. По этой причине все усилия разработчиков как правило направлены на минимизацию количества этих переключений. Поэтому, например, никто не рисует попиксельно в видеопамяти, а либо вызывает соответствующую глобальную функцию отрисовки в драйвере, либо рисует в памяти и вызывает функцию копирования. В целом получается быстрей постоянных переключений/вызовов. Прямые дополнительные расходы в микроядре получаются - несколько ассемблерных инструкций для смены контекста и расходы на перезагрузку CR3 (смена виртуального адресного пространства). Перезагрузка CR3, уже считали, приводит к потере производительности в доли процента. Потери на смену контекста будут зависеть от количества вызовов в единицу времени, но как я уже отметил, всеобщая тенденция направлена на их минимизацию потому что эти вызовы и без того трудозатратны. Самая большая проблема "классического" микроядра - не только переключение контекстов но и передача данных между ними: ядром получен запрос на чтение файла (1) передаем запрос менеджеру безопасности - проверка прав доступа (2) менеджер безопасности возвращает права (3) передаём запрос подсистеме ввода-вывода - надо определить что за устройство и направить туда запрос (4) IO запрашивает менеджер кэша - возможно данные уже в памяти (5) неудачно - передаем запрос драйверу файловой системы (6) запрос драйверу диска (7) данные считаны и передаются драйверу файловой системы (8) драйвер файловой системы передает данные IO (9) IO уведомляет менеджер кэша что в памяти есть такие данные (10) IO возвращает данные ядру (11) ядро отдает данные в пользовательский процесс. Это совершенно навскидку, наверно что-то ещё забыл, например - надо получать страницы и т.п. В монолитных системах это простые вызовы процедур без передачи данных между пространствами а в микроядре мы вынуждены постоянно передавать данные (например - 8-16 страниц), да ещё и манипулировать с правами на эти данные. Понятно, что без хитростей не обходится, но радикально от недостатка избавится нельзя. Ещё одна засада - когда отдельное адресное пространство для ОС и задач - опять усложнение за счёт того, что ОС не может напрямую манипулировать данными в пользовательском пространстве - надо отображать. Хотя сам я тоже думаю о том, что микроядро перспективнее... |
Автор: | shm [ 08 ноя 2012, 22:33 ] |
Заголовок сообщения: | Re: Идея универсальный драйверов |
Нафлудили... Станислав, завязывай оффтопить, если нечего сказать по делу. Передо мной сейчас стоят два ПК и на все их потроха можно без проблем найти официальные маны (коме видеокарточек). лучше все равно не напишешь. Ты хочешь наклепать кучу непродуманных и недоделанных драйверов, это не серьезно. Лучше пусть у тебя будет 1 драйвер вместо 10ти, но реально продуманный, законченный и отлаженный. pavia писал(а): Но с нуля писать драйвер HDD не собираюсь. Ну во-первых тебя никто и не заставляет. Во-вторых, если даже и хочешь его унифицировать, то непонятно зачем все переписывать. ИМХО реально достаточно будет ограничиться некоторыми обертками и небольшими допилами. Почитал твою обработку прерываний... как то ты мутно описал. Все равно в конце концов у тебя будет вызван нужный обработчик прерывания, что собственно и нужно. Yoda писал(а): Обмен событиями производится через прямые вызовы функций драйвера (во всех трёх типах) и через коллбэки (3-й тип) Вот тут, пожалуйста, поподробнее. Что-то я не могу представить как это будет происходить с учетом того, что как вызывающая сторона так и драйвер - это отдельные задачи. SII писал(а): Не всегда достижимо: для драйверов древнего оборудования необходимы IN и OUT Это на самом деле мелочи, при большом желании их тоже можно отобразить на память к примеру. Станислав писал(а): Драйвер для HDD можно ограничить функцией идентификации, чтения секторов и запись секторов, а это просто. Ну как минимум нужны еще функции управления кэшем и желательно хоть какой-нить уровень поддержи ACPI. Короче я изучил мнения людей, в связи с чем предлагаю три варианта: 1. Клиент-серверная модель. 2. Гибридная. 3. Модуль пространства ядра. В своих постав, пожалуйста, явным образом отразите какую модель вы бы желали унифицировать. |
Автор: | SII [ 09 ноя 2012, 00:00 ] |
Заголовок сообщения: | Re: Идея универсальный драйверов |
Yoda писал(а): SII писал(а): Не всегда достижимо: для драйверов древнего оборудования необходимы IN и OUT. Согласен. Но для этого есть промежуточные кольца защиты, их и следует задействовать. А в 64-разрядном режиме это работает? (Я уже давно отошёл от IA-32, а посему многого не помню -- особенно того, с чем плотно работать не приходилось). Цитата: SII писал(а): 1) Если требуется одно лишнее переключение контекста -- да, таковым можно пренебречь (будет медленней, но общая разница слишком мала). Однако нередко требуется пропустить запрос ввода-вывода через целый стек драйверов. Я понял твою мысль. Операция файлового ввода/вывода должна сначала пройти проверку прав доступа, затем пройти через драйвер файловой системы, затем через очередь (или кэш) операций блочного I/O и только затем попасть в драйвер устройства. Как я уже писал ранее, давай в данном контексте под драйвером понимать драйвер именно железки. В конце концов, промежуточные уровни (назовём их сервисами, хотя, конечно, в общем случае это не всегда так) можно интегрировать в ядро при относительно низкой потере надёжности. Их немного и с ними проще работать. Я говорю про выделение в отдельное пространство части аппаратного драйвера. В таком случае производительность пострадает не сильно. Как ни называй, смысл от этого не меняется. Вероятность наличия ошибок в большой и сложной программе (драйвере файловой системы, к примеру -- или, если угодно, в сервисе ) обычно всё же существенно выше, чем в маленькой и довольно простой (драйвере контроллера дисков). Так что с точки зрения надёжности логичнее как раз большие и сложные куски вытаскивать из ядра, а не наоборот -- тем более, что подобные куски как раз и не нуждаются в привилегированных операциях, поскольку им не нужен доступ к самому железу, а вот драйверам железа нужен. (Кстати, именно так сделано в графической подсистеме Вислы и Винды 7: в ядре оставлен лишь сравнительно небольшой и простой драйвер, прямо работающий с видюхой, а более высокоуровневые компоненты, включая компилятор шейдеров, вынесены в пространство пользователя). Кроме того, этих самых промежуточных уровней может быть достаточно много, а сами они могут меняться (например, появляются новые файловые системы); соответственно, просто так интегрировать их в ядро нельзя. Что же до надёжности, то сама по себе она не зависит от архитектуры системы, и это мы, кажется, уже обсуждали (и каждый остался при своём мнении, как обычно ). Цитата: По этой причине всё пикоядро... Которое и должно было бы называться микроядром, а не монстры типа QNX Вот она, инфляция терминологии Цитата: То есть, да, потери есть, но всё же их масштаб обычно преувеличивают Ну, потери в сумме будут не в десятые доли процента, хотя и не в разы. Но я-то принципиальный противник микроядерности не из-за этих потерь как таковых, а из-за того, что ложно основное обоснование перехода на микроядро -- повышение надёжности работы системы в целом. Если же повышения надёжности нет, то зачем терять производительность? Цитата: И надеяться я как раз могу . Ну хорошо, хорошо. Надеяться можно, но рассчитывать -- нельзя |
Автор: | Станислав [ 09 ноя 2012, 02:53 ] |
Заголовок сообщения: | Re: Идея универсальный драйверов |
shm писал(а): Нафлудили... Станислав, завязывай оффтопить, если нечего сказать по делу. Передо мной сейчас стоят два ПК и на все их потроха можно без проблем найти официальные маны (коме видеокарточек). лучше все равно не напишешь. Ты хочешь наклепать кучу непродуманных и недоделанных драйверов, это не серьезно. Лучше пусть у тебя будет 1 драйвер вместо 10ти, но реально продуманный, законченный и отлаженный. Я только хочу обсуждать алгоритмы работы контроллеров, спеки и делать обзоры, а на этой базе уже будут реализованы драйвера, причём моя версия драйвера не обязательно будет хуже твоей. shm писал(а): Ну как минимум нужны еще функции управления кэшем и желательно хоть какой-нить уровень поддержи ACPI. Я думал ты скажеш обработка ошибок, как ты это часто говориш. ACPI нужна не для драйвера, а для системы. Должна быть система работающая и хорошо описанная работа в ней, а потом уже драйвера для неё. Драйвер это только работа в регистрах контроллера и выделенном буфере памяти для него, а прерывания проверяют биты устройства и будят объекты запросившие данные с устройства и всё. |
Автор: | pavia [ 09 ноя 2012, 11:24 ] |
Заголовок сообщения: | Re: Идея универсальный драйверов |
Меня больше устроит клиент-серверная. Так как хочу микро ядро попробовать. Гибрид тоже устроит, так как на данный момент система гибридная. С прерываниями пришлось извращаться для защиты системы от кривых драйверов. Драйвера и ядро планирую вынести в 1 кольцо. Это особенность х86. В х86-64 нормально моюно разместить в 0. Вы ещё незнаете что я со страницами напридумывал. Станислав недавно в осдеве и поэтому горяч. Драйвер написать легко. А вот написать такой что бы неглючил и работал с любой железкой очень непросто. Вот хочешь ты показать ОС своему другу а у него видеокарта не дружит с веса и начинает вывод первой точки с середины монитора и вместо 1 жёсткого детектится 2 !!! ( из личной практики) |
Автор: | shm [ 09 ноя 2012, 11:49 ] |
Заголовок сообщения: | Re: Идея универсальный драйверов |
Станислав писал(а): Я думал ты скажеш обработка ошибок, как ты это часто говориш. Это само собой разумеющиеся вещи. |
Автор: | shm [ 09 ноя 2012, 11:51 ] |
Заголовок сообщения: | Re: Идея универсальный драйверов |
Станислав писал(а): ACPI нужна не для драйвера ACPI нужна системе и поддержку ее рамках конкретной железки должен обеспечить драйвер, посмотри как тот же Линуксовый драйвер организован и убедись сам. Завязывай с оффтопом. |
Автор: | shm [ 09 ноя 2012, 11:58 ] |
Заголовок сообщения: | Re: Идея универсальный драйверов |
pavia писал(а): С прерываниями пришлось извращаться для защиты системы от кривых драйверов. Т. е. у тебя сейчас уже какие-то сторонние драйверы поддерживаются? А так-то, на мой взгляд, это вполне разумное решение. |
Страница 4 из 5 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |