OSDev http://osdev.su/ |
|
Идея универсальный драйверов http://osdev.su/viewtopic.php?f=5&t=646 |
Страница 5 из 5 |
Автор: | Yoda [ 09 ноя 2012, 13:38 ] |
Заголовок сообщения: | Re: Идея универсальный драйверов |
shm писал(а): Yoda писал(а): Обмен событиями производится через прямые вызовы функций драйвера (во всех трёх типах) и через коллбэки (3-й тип) Вот тут, пожалуйста, поподробнее. Что-то я не могу представить как это будет происходить с учетом того, что как вызывающая сторона так и драйвер - это отдельные задачи. Я говорю про интерфейс самого драйвера. Он может быть и в составе ядра, тогда это не отдельные задачи. В данном случае ядро или линкует драйвер с собой, и тогда просто вызывает функции, либо транслирует передачу сообщений между задачами в вызов функции драйвера. В этом случае драйвер грузится в отдельное адресное пространство и линкуется с обёрткой, осуществляющей трансляцию. shm писал(а): Станислав писал(а): Драйвер для HDD можно ограничить функцией идентификации, чтения секторов и запись секторов, а это просто. Ну как минимум нужны еще функции управления кэшем и желательно хоть какой-нить уровень поддержи ACPI. Ну ещё как минимум нужны функции ПОЛНОЙ идентификации устройства (производитель, модель, серийный номер, количество секторов, CHS-геометрия, размер сектора, seek-penalty, поддержка режимов UDMA и LBA-адресации) и управления SMART. shm писал(а): 1. Клиент-серверная модель. 2. Гибридная. 3. Модуль пространства ядра. Не пойму, что подразумевается под клиент-серверной и гибридной моделью и в чём между ними разница. Категорически возражаю против модуля пространства ядра. SII писал(а): А в 64-разрядном режиме это [кольца защиты] работает? (Я уже давно отошёл от IA-32, а посему многого не помню -- особенно того, с чем плотно работать не приходилось). Честно говоря, не знаю. С 64-битной архитектурой пока плохо знаком, хотя, конечно, ей нужно плотно заняться. Но думаю, там обязательно должны быть механизмы, технически позволяющие выполнять ввод/вывод непривилегированным задачам. SII писал(а): Как ни называй, смысл от этого не меняется. Вероятность наличия ошибок в большой и сложной программе (драйвере файловой системы, к примеру -- или, если угодно, в сервисе ) обычно всё же существенно выше, чем в маленькой и довольно простой (драйвере контроллера дисков). Во-первых, файловых систем, с которыми работает ОС, как правило, очень немного. Алгоритмов кэширования и того меньше. А вот разных железок - тысячи и авторы их [закрытых] драйверов легко могут накосячить, а то и устроить целенаправленный взлом или компрометацию системы. Поэтому я теоретически допускаю введение некоторых уровней, за которые отвечает сам разработчик ОС, в пространство ядра. С другой стороны, как я уже сказал, соотношение надёжность/производительность при определённом подходе можно варьировать. Для этого драйвер (или сервис) должен быть сделан так, чтобы он мог быть как прилинкованным к ядру, так и работать в отдельном пространстве. SII писал(а): тем более, что подобные куски как раз и не нуждаются в привилегированных операциях, поскольку им не нужен доступ к самому железу, а вот драйверам железа нужен. (Кстати, именно так сделано в графической подсистеме Вислы и Винды 7: в ядре оставлен лишь сравнительно небольшой и простой драйвер, прямо работающий с видюхой, а более высокоуровневые компоненты, включая компилятор шейдеров, вынесены в пространство пользователя). Это называется "библиотечный" подход, когда часть функций реализована в виде расшаренных библиотек, работающих в пространстве пользователя. Такой подход должен использоваться вообще по максимуму, как наиболее безопасный и производительный. Конечно, сам драйвер должен включать только те функции, которые непосредственно требуются для работы с устройством. Я об этом уже говорил. SII писал(а): Кроме того, этих самых промежуточных уровней может быть достаточно много, а сами они могут меняться (например, появляются новые файловые системы); соответственно, просто так интегрировать их в ядро нельзя. ...а значит они должны быть реализованы в виде сервиса, работающего в отдельном пространстве. Всё логично. SII писал(а): Но я-то принципиальный противник микроядерности не из-за этих потерь как таковых, а из-за того, что ложно основное обоснование перехода на микроядро -- повышение надёжности работы системы в целом. Если же повышения надёжности нет, то зачем терять производительность? Теоретически, повышение надёжности есть. А если его нет на практике, то это - ошибка проектировщика или программиста, которые не смогли его реализовать. |
Автор: | Станислав [ 09 ноя 2012, 15:35 ] |
Заголовок сообщения: | Re: Идея универсальный драйверов |
Цитата: Ну ещё как минимум нужны функции ПОЛНОЙ идентификации устройства (производитель, модель, серийный номер, количество секторов, CHS-геометрия, размер сектора, seek-penalty, поддержка режимов UDMA и LBA-адресации) и управления SMART. С HDD идентификация 512мб инфы, там всё есть. Вообще немного не понимаю ваших проблем, т.к. для всех дсков драйвер один и не сложный. функции ACPI реализуются в системе а драйвер пользуется ими. Своё прерывание включить, или MSI там настроить. Проблема в драйверной модели и форате файла. Что должно быть в файле, бинарный код и таблица релокации. Какие функции будут в драйвере? Не проще будет в виде исходного кода? Может быть предложет ктонить вариант готового оформления, а то долго так можно переписываться. |
Автор: | shm [ 09 ноя 2012, 21:48 ] |
Заголовок сообщения: | Re: Идея универсальный драйверов |
Yoda писал(а): В этом случае драйвер грузится в отдельное адресное пространство и линкуется с обёрткой, осуществляющей трансляцию. Если я правильно понял, то у тебя и получается фактически та же самая модульная архитектура, только каждый модуль грузится в свое адресное пространство. И смысл обертки насколько я понял - управлять вызовом процедур в разных адресных пространствах. В таком случае за основу тебе как раз и подойдет модульная архитектура. Yoda писал(а): Ну ещё как минимум нужны функции ПОЛНОЙ идентификации устройства Так он это сказал. Yoda писал(а): управления SMART Тоже бы неплохо, но считаю, что поддержка данного функционала не должна быть обязательной. Yoda писал(а): Не пойму, что подразумевается под клиент-серверной и гибридной моделью и в чём между ними разница. Категорически возражаю против модуля пространства ядра. Вот http://club.shelek.ru/viewart.php?id=66 описано на примере QNX. В книге Таненбаума также подробно описано. Гибридная модель - это когда часть драйверов (или даже часть драйвера) работает в пространстве ядра, остальные - в виде отдельных клиент-серверных приложений. По модульной архитектуре сказал уже выше. Станислав писал(а): С HDD идентификация 512мб инфы Байт. Станислав писал(а): т.к. для всех дсков драйвер один и не сложный. Для SCSI и ATA, ты уверен? Станислав писал(а): функции ACPI Ты, по всей видимости, несколько сужено трактуешь этот стандарт. Станислав писал(а): Что должно быть в файле, бинарный код и таблица релокации. Само собой. Станислав писал(а): Какие функции будут в драйвере? Будем обсуждать отдельно. Станислав писал(а): Не проще будет в виде исходного кода? Не проще, попробуй прикрутить исходник драйвера Линуха / Винды (тоже можно найти в сети) к себе. И не каждый согласиться раздавать исходники. Станислав писал(а): Может быть предложит ктонить вариант готового оформления, а то долго так можно переписываться. Не, если кто-то предложит один, то однозначно никто, кроме него самого не согласиться реализовать данный стандарт. А переписываться придется долго, это да. Я все же надеюсь получит вариант, который устроит всех. |
Автор: | Yoda [ 09 ноя 2012, 23:52 ] |
Заголовок сообщения: | Re: Идея универсальный драйверов |
shm писал(а): Если я правильно понял, то у тебя и получается фактически та же самая модульная архитектура, только каждый модуль грузится в свое адресное пространство. И смысл обертки насколько я понял - управлять вызовом процедур в разных адресных пространствах. Да, всё верно. |
Страница 5 из 5 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |