> И? Если у кого-то не было желания тестировать свой код (в том
> числе и писать тесты), то почему вдруг при изменении архитектуры что-нибудь
> поменяется?Если появляется возможность - то под давлением давних проблем, ею начнут пользоваться.
Хотя да, это просто открытая возможность, ни к чему не обязывающая.
Даже если продолжать писать код, как счас - всё равно система будет куда стабильнее.
>> Да и сейчас, в монолитном виде тестировать отдельные модули ядра, кроме как
>> собрать ВСЁ, загрузить и погонять - некак. (а хоть какие-то тесты
>> есть только в btrfs модуле)
>> Остаётся не у дел самый эффективный подход - разработка через тестирование. Причём,
>> в самой критичной части операционки...
>> Микроядерный же подход позволяет имитировать микроядро для модуля, и делая контрольные
>> вызовы - контроллировать что модуль зовёт дальше: есть ли нужные обращения
>> к железу (через выховы микроядра) и прочим сервисам.
> Ну вообще-то и в текущем ядре это сделать не проблема, микроядро здесь
> скорее все усложнит.
Сейчас, чтобы протестировать работу драйвера (не уронив саму систему, где идёт разработка) нужно:
сделать так, чтоб драйвер компилился на уровне пользователя
добавить каких-нить заглушек на оконечную работу модуля с железом
и уже собсно, автоматически тестировать (на основе контроля правильности вызова этих заглушек).
Микроядро же - сразу даёт первых 2 пункта в готовом виде.
Ну практически полная аналогия если сравнивать написание модуля под монолит и разработка обычной юзер-левел проги.
> Есть скажем штуки 3 функции для записи регистров
> устройств (байт, два байта, 4 байта), переопредели их и вот ты
> контролируешь работу с железом.
Да, и это нужно делать всем разработчикам железодров, каждый по-своему.
Или может один раз это сделать займёт меньше времени? (те самые линуксовые человеко-часы)
> другой вопрос что
> а)Это скучно и не интересно писать тесты, как здесь поможет какая-либо другая
> архитектура?
> б)Набор функций маленький, но количество комбинация их вызовов и соотвественно
> объем тестирования огромный, как здесь опять может какая-либо другая архитектура?
Дрова часто (не всегда) пишут те, кто проэктировал железку, т.е. они и так знают как и на какие команды она должна реагировать. По сути, тесты уже есть (вопрос формата).
А насчёт скучно - так рутовая уязвимость в левой пятке ненужного драйвера на нескольких тысячах серваков с юзерским ssh доступом - завсегда прибавит веселья.
И так раз в год-полгода СТАБИЛЬНО. И просвета в монолитом НЕ ВИДАТЬ.
