1. Вы глобально путаете две вещи:
а) сбой в драйвере и
б) реакция ядра на это событиеПример:
"Так вот, мне надо драйвер который просто печатает,
просто играет звук, просто выводит картинку и просто работает.А краши и
запасные парашюты на случай если д*рьмо случится - пожалста оставьте себе."
Всем нужны _просто_ драйвера. Но вот кое-кому не хочеться терять всю систему если один драйвер стал раком.
Заметьте, плз, вот здесь речь _НЕ_ о качестве драйвера, т.е. НЕ о сбое в нем. И даже не о процессе создания драйвера: кто в нем на опасность какого креша забил - уже неважно. Есть готовый драйвер и в нем произошел сбой.
Речь о пункте "б" - реакия системы.
И тут выбор прост: отдаццо на волю случая (драйвера) или что-то решать.
Вы ясно дали понять, что готовы отдаться на волю случая, т.е. лучше чтоб все упало разом.
Но может выскажетесь по второму пункту? Что если воля случая не устраивает - и нужно что-то решать? Идеи кроме микроядра есть?
2. Разница между драйвером/программой/задачей/процессом.
В линуксе она отсутсвует :) Это все почти синонимы.
Просто характеризуют какой-либо набор инструкция процессора, направленных на решение како-либо задачи.
Ну а драйвера - они просто (в монолитном ядре, текущем Линухе) делят адрессное пространство с ядром. Т.е. они все и ядро - в одном адрессном пространстве.
А пользовательские прграммы - железно в другом. Хотя и несколько пользовательских процессов так же могут жыть в общем (для них) адрессном пространстве.
3. У вас явно проблемы с иксами :)
Не знаю откуда и почему - не тут это обсуждать.
Просто хотел дать совет (а кто его послушает?? ;)
Если вы теряете такие уж важные данные при падении иксов - ну запустите какой-нить виртуальный X сервер (типа vnc, например), и подключайтесь к нему уже из обычных иксов.
Если они упадут - ну придеццо просто переподключиться к vnc серверу :) Ниче не будет потеряно.
Неправда ли, разнесение функционала в самостоятельные процессы - несколько сглаживает (если не решает) данную проблему? Ну так почему же вы тогда так против подобного решения для драйверов?
>наворачивание иксов способно порадовать линуксоида невзирая на то что
>упал всего-то какой-то "юзерский" процесс а вовсе и не драйвер.
Вот после схемы с vnc - так оно и будет. У вас упадет просто "консоль" к вашим программам,
который легко перезапускаеться (и при новая копия ничего не портит по пути, как вы утверждали тут про перезапуск драйверов ФС или винта).
>Данные при
>этом имеют подлое свойство не сохраняться в этой ситуации.Если вы не
>сохранили файл, шанса это сделать при падении иксов никто не даст
ну так веть вот он. Шанс ваш ;)
4. Очевидно, вы не совсем понимаете о чем спор.
>>(монолит пусть живет своей жизнью/веткой, к нему как к монолиту претезний мало).
>Я про то и говорю - на кой черт его лечить от того чем он особо и не страдает?
монолит действительно я не собираюсь лечить. Как монолит - текущий линух весьма неплох.
Я говорю о совершенно другом ядре. Не монолите. И допускаю, что подобные изменения в Линухе заслуживали бы на отдельную major версию: 3.
И у вас какие-то комплексы по поводу названия подобного ядра...
Да, это мог бы быть Линух. Если переделывать его - то это именно и будет Линуксом.
Просто у него будут достаточно большие изменения в структуре, что и молго бы быть отмечено отдельной веткой разработки.
А про "линукс это круто" - да, круто. Пока в нем больше всего открытый драйверов, чем в любом другом ядре на Земле - да, это круто.
Его можно изменять и дорабатывать безо всяких лицензионных проблем. Это круто.
Переделать именно Линукс БЕЗ потери _всей_ его функциональности (допустима некоторая потеря производетельности, но _не_ функциональности) - самый простой и быстрый путь к постоению микроядра уровня Линуха (меньше - просто не нужно).
Почему тогда какие-то предъявы по этому поводу? Или у вас с крутостью Линукса связаны какие-то другие мысли??
5. Попытки решить проблему есть и в текущем монолите.
Внутриядреное ограничение доступа имееться и может быть включено опцией при сборке.
Это запрет на запись в области кода.
Да, действительно, падающий драйвер вряд-ли будет снимать защиту (хотя он это может)
с областей, где ему срочно нужно попортить память :)
Но это не решает проблему. Потому как данные то всех модулей (драйверов) остаються доступными всем на RW. И не в них ли собираеться отспамиться перед смертью очередной кривой ядерный процесс??
6. SELinux. Судя по вашему посту и "замену ACLями rwx" - вы не вкурсе для чего он нужен.
Это нестрашно - прочитаете если будет нужно.
Но вот его суть именно в том, что каждый процесс обладает только теми правами (на ФС это не ограничиваеться), которые ему нужны для работы. Шаг влево/право ему не даст сделать ядро.
Так вот про "не прыгает по 10 раз между системой и юзеров ради разруливания запроса".
Еще и как прыгает. Каждый (!!) системный вызов наделяеться дополнительными проверками по таблице разрешений. Может конечная нагрузка таких проверок и меньше, чем переключения контекста в микроядре, но эти две технологии и разные проблемы то решают...
Так что: добавление любой защиты - это почти всегда понижение производительности.
7. Драйвер, в общем случае, может привести устройство, которым он управляет в невменяемое состояние так, что и новая копия драйвера может не разрулить ситуацию. Иной раз даже после ресета...
Так что, не нам страдать от того что драйвер видухи может ее завесить и даже микроядро ничего не сможет с этим сделать.
У микроядра НЕ эта задача. Тут опять идет путаница понятий из первого пункта.
Микроядро, если драйвер упал, - пытаеться решить что делать софту дальше.
Если новоперезапущенный драйвер видухи не справляеться с ней - то это точно не проблема микроядра. Оно свое дело сделало. Остальное - проблема производителя видухи и драйвера.
И если вендор не правит свои дрова, зная о проблемах - ессьно, нужно менять вендора.
Но это не касаеться структуры ядра! Это вопросы иного рода совершенно.
Самое интересное, что это все не меняеться и для монолитного ядра.
Там все так же чинить драйвер и железо - производителю.
Так может не будем путать теплое с мягким: поведение ядра при падении драйвера и починит ли производитель этот драйвер когда-нибудь?
8. Ну и конечно же стоит бороться за открытость драйверов.
Но, это не тема текущего разговора. Это политика. А мы - про технику пока что.
