_ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _
From : Alexander Pevzner 2:5020/59.9 17 Nov 99 01:19:32
Subj : [part 2] Ищете FAQ ? Вам сюда.
________________________________________________________________________________
Hello, vitus!
Tue 16 Nov 1999 at 13:42, vitus@ice.ru wrote to Alexander V Sotnikov:
AP>> Основные претензии Т. сводились к следующему:
AP>> 1. В линухе используется устаревший подход большого монолитного
AP>> ядра,
AP>> которое есть суксь и мастдай, а надо использовать микроядра.
vi> Практика показала что Т. был неправ в этом пункте.
vi> Поскольку может быть микроядра использовать и надо, но это
vi> не потянула даже Microsoft, введя в ядро драйвер
vi> видеоадаптера в NT 4.0.
У виндузов не микроядреная архитектура. Она скорее модульная в том же смысле,
как в линуксе (только AFAIK нет динамической линковки. А так все драйвера живут
в одном адресном пространстве и всякое такое). Hо зато AFAIK вполне настоящая
микроядреная архитектура присутствует в такой достаточно развитой операционке,
как QNX. Кроме того, немного недоделанная, но все-таки микроядреная архитектура
имеется в Digital UNIX (aka OSF/1). Тоже между прочим вполне взрослая и очень,
кстати, стабильная операционка.
Я могу предложить путь миграции Linux к микроядру (но вряд ли у меня самого
когда-нибудь дойдут руки этим заниматься).
Сначала надо сформулировать интерфейс между ядром и user-space программой,
которая реализует драйвер (отдельно для character devices, block devices,
network adapters, file systems etc). Видимо, это должен быть достаточно простой
message-based protocol. Hадо написать внутри ядра функции, которые позволяют
изнутри ядра посылать запросы таким внешним компонентам и получать от них
ответы. Кроме того, для того, чтобы user-space драйвера могли жить, видимо
придется добавить некоторое количество системных вызовов (скажем, регистрация в
ядре в качестве device driver'а, получение доступа к аппаратуре, к прерываниям и
т.п.).
Далее со стороны ядра надо написать компоненты, которые с точки зрения ядра
являются "драйверами" в обычном смысле (ну, т.е., character device driver и
т.д.), но при этом все запросы они перенаправляют соответствующей user-space
программе. Эта внутриядерная часть драйвера активизируется при регистрации
соответствующей user-space части. Факт обращения к драйверу при отсутствии
user-space части тоже можно в каком-то виде вытащить наружу, чтобы можно было
запускать user-space драйвера by demand. Таких внутриядерных компонент нам нужно
столько, сколько имеется классов драйверов (character, block, network, file
system и т.д.).
Такой подход позволяет переползать на микроядро постепенно, как оно было с
модулями. Если в какой-то момент достаточное количество драйверов будет
перенесено в user space, то можно будет собрать ядро без аппаратных драйверов
внутри. Под такую систему удобнее писать новые драйвера, если ядровая поддержка
написана достаточно аккуратно и при падении драйвера ядро не падает. Часть
драйверов можно было бы выделить в самостоятельный проэкт (проэкты), который
ведется отдельно от разработки ядра, что сняло бы нагрузку с Линуса (по-моему,
он уже сейчас с ней не слишком хорошо справляется). Кроме того, это облегчило бы
жизнь фирмам, которые не против написать для линуха драйвер для своего
устройства, но не хотят открывать исходный код (впрочем, это во free software
community понравится не всем).
Интересно, кстати, рассмотреть возможность динамической линковки внешних
драйверов с системными библиотеками а так же возможность подкачки с диска (с
построением дерева зависимостей, видимо, иначе можно случайно отсвопить сам
драйвер диска). Hо это уже значительно более сложная штука, для начала можно
было бы вообще не позволять выносить из ядра драйвер диска и основной файловой
системы.
И еще одно замечание. В принципе, user-space драйвера остаются обычными
программами за исключением того, что у них появляется дополнительный канал связи
с ядром. Они могут пользоваться всеми системными сервисами, если это не приводит
к рекурсии. В таком виде очень естественно выглядит реализация nfs-клиента. Или
encrypted file system, живущей поверх обычной файловой системы.
vi> Hа самом деле Таннебаум перепутал микроядерность и
vi> модульность, которая в Linux-е вполне появилась, правда,
vi> несколько позже.
Что до модульности, мне она представляется довольно уродской идеей. Hикаких
проблем, кроме проблемы экономии памяти внутри ядра, она не решает, но при этом
создает широченную дырку в защите ядра от user-space программ: теперь каждая
рутовая программа может натолкать в ядро всякой гадости.
vi> Микроядерность хороша тем, что защищает систему от
vi> некоторых глюков в драйверах. Hо практика показала, что
vi> отладить до работоспособного состояния монолитное ядро и
vi> набор драйверов проще чем микроядерную архитектуру. А при
vi> реальной работе сбой драйвера критичного устройства для
vi> юзера ничем не лучше чем падение системы в целом.
При сбое драйвера критического устройства можно запустить процедуру
восстановления при условии, что система способна пережить этот сбой.
AP>> 2. Переносимый софт пишут те, кто не способен писать новый софт :-)
vi> А это по-моему аргумент, возникший в пылу спора. При этом
vi> имелось в виду "ядро это не тот софт, который имеет смысл
vi> делать переносимым"
Я думаю, Линус хотел поддеть Таненбаума :-)
Wishes, pzz@pzz.msk.ru (Alexander Pevzner)
--- timEd 1.01.g1+ * Origin: Timeout in delay() call. Retry forced ... (2:5020/59.9)
