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 писал(а):
Но я-то принципиальный противник микроядерности не из-за этих потерь как таковых, а из-за того, что ложно основное обоснование перехода на микроядро -- повышение надёжности работы системы в целом. Если же повышения надёжности нет, то зачем терять производительность?
Теоретически, повышение надёжности есть. А если его нет
на практике, то это - ошибка проектировщика или программиста, которые не смогли его реализовать.
Вход
Регистрация
FAQ
Поиск
