The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Линус Торвальдс выступил с критикой контроля качества в  DRM..., opennews (?), 27-Фев-17, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


57. "Линус Торвальдс выступил с критикой контроля качества в  DRM..."  +3 +/
Сообщение от мегааноним_email (?), 27-Фев-17, 12:29 
> Кто-то ещё сомневается, что Линуксу давно пора менять дизайн на микроядро?
> Это ж оно в сабже просто не скомпилилось у Торвальдса. А если
> бы скомпилилось? Но никакого тестирования то там всё так же и
> не было...

И? Если у кого-то не было желания тестировать свой код (в том числе и писать тесты), то почему вдруг при изменении архитектуры что-нибудь поменяется?

> Да и сейчас, в монолитном виде тестировать отдельные модули ядра, кроме как
> собрать ВСЁ, загрузить и погонять - некак. (а хоть какие-то тесты
> есть только в btrfs модуле)
> Остаётся не у дел самый эффективный подход - разработка через тестирование. Причём,
> в самой критичной части операционки...
> Микроядерный же подход позволяет имитировать микроядро для модуля, и делая контрольные
> вызовы - контроллировать что модуль зовёт дальше: есть ли нужные обращения
> к железу (через выховы микроядра) и прочим сервисам.

Ну вообще-то и в текущем ядре это сделать не проблема, микроядро здесь скорее все усложнит. Есть скажем штуки 3 функции для записи регистров устройств (байт, два байта, 4 байта), переопредели их и вот ты контролируешь работу с железом.
API ядра которое использует DRM тоже считанные функции,

в общем переопределив штук 30 функций можно полностью котролировать драйвер и
писать для него тесты, другой вопрос что

а)Это скучно и не интересно писать тесты, как здесь поможет какая-либо другая архитектура?
б)Набор функций маленький, но количество комбинация их вызовов и соотвественно
объем тестирования огромный, как здесь опять может какая-либо другая архитектура?

> Ну и излишне говорить о безопасности, даже если какая ошибка вкрадётся в
> какой сервис - это всё-таки, уже отдельный процесс. Даже если навернётся
> - то будет просто перезапущен. Всё остальное продолжит работу.

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

72. "Линус Торвальдс выступил с критикой контроля качества в  DRM..."  –1 +/
Сообщение от Аноним (-), 27-Фев-17, 12:57 
> в общем переопределив штук 30 функций можно полностью котролировать драйвер и

писать для него тесты

И что вы собираетесь таким образом тестировать ?

Ответить | Правка | Наверх | Cообщить модератору

94. "Линус Торвальдс выступил с критикой контроля качества в  DRM..."  –1 +/
Сообщение от Анонимм (??), 27-Фев-17, 13:27 
> И? Если у кого-то не было желания тестировать свой код (в том
> числе и писать тесты), то почему вдруг при изменении архитектуры что-нибудь
> поменяется?

Если появляется возможность - то под давлением давних проблем, ею начнут пользоваться.
Хотя да, это просто открытая возможность, ни к чему не обязывающая.
Даже если продолжать писать код, как счас - всё равно система будет куда стабильнее.


>> Да и сейчас, в монолитном виде тестировать отдельные модули ядра, кроме как
>> собрать ВСЁ, загрузить и погонять - некак. (а хоть какие-то тесты
>> есть только в btrfs модуле)
>> Остаётся не у дел самый эффективный подход - разработка через тестирование. Причём,
>> в самой критичной части операционки...
>> Микроядерный же подход позволяет имитировать микроядро для модуля, и делая контрольные
>> вызовы - контроллировать что модуль зовёт дальше: есть ли нужные обращения
>> к железу (через выховы микроядра) и прочим сервисам.
> Ну вообще-то и в текущем ядре это сделать не проблема, микроядро здесь
> скорее все усложнит.

Сейчас, чтобы протестировать работу драйвера (не уронив саму систему, где идёт разработка) нужно:
сделать так, чтоб драйвер компилился на уровне пользователя
добавить каких-нить заглушек на оконечную работу модуля с железом
и уже собсно, автоматически тестировать (на основе контроля правильности вызова этих заглушек).
Микроядро же - сразу даёт первых 2 пункта в готовом виде.

Ну практически полная аналогия если сравнивать написание модуля под монолит и разработка обычной юзер-левел проги.


> Есть скажем штуки 3 функции для записи регистров
> устройств (байт, два байта, 4 байта), переопредели их и вот ты
> контролируешь работу с железом.

Да, и это нужно делать всем разработчикам железодров, каждый по-своему.
Или может один раз это сделать займёт меньше времени? (те самые линуксовые человеко-часы)

> другой вопрос что
> а)Это скучно и не интересно писать тесты, как здесь поможет какая-либо другая
> архитектура?
> б)Набор функций маленький, но количество комбинация их вызовов и соотвественно
> объем тестирования огромный, как здесь опять может какая-либо другая архитектура?

Дрова часто (не всегда) пишут те, кто проэктировал железку, т.е. они и так знают как и на какие команды она должна реагировать. По сути, тесты уже есть (вопрос формата).
А насчёт скучно - так рутовая уязвимость в левой пятке ненужного драйвера на нескольких тысячах серваков с юзерским ssh доступом - завсегда прибавит веселья.
И так раз в год-полгода СТАБИЛЬНО. И просвета в монолитом НЕ ВИДАТЬ.

Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

236. "Линус Торвальдс выступил с критикой контроля качества в  DRM..."  +1 +/
Сообщение от мегааноним_email (?), 27-Фев-17, 18:19 
> Сейчас, чтобы протестировать работу драйвера (не уронив саму систему, где идёт разработка)
> нужно:
> сделать так, чтоб драйвер компилился на уровне пользователя
> добавить каких-нить заглушек на оконечную работу модуля с железом
> и уже собсно, автоматически тестировать (на основе контроля правильности вызова этих заглушек).
> Микроядро же - сразу даёт первых 2 пункта в готовом виде.
> Ну практически полная аналогия если сравнивать написание модуля под монолит и разработка
> обычной юзер-левел проги.

Для ядра в user space есть архитектура "um", и еще конечно qemu,
так что первые 2 пункта и для Linux есть том же относительно готовом виде.

> Дрова часто (не всегда) пишут те, кто проэктировал железку, т.е. они и
> так знают как и на какие команды она должна реагировать. По
> сути, тесты уже есть (вопрос формата).

Блин, почитайте про юнит тесты и multithreading,
а прерывания (которые используют практически любая железка)
дают тот же эфект внезапного переключения контекста,
все еще думаете что это легко написать тест который реально что-то тестирует?


Ответить | Правка | Наверх | Cообщить модератору

239. "Линус Торвальдс выступил с критикой контроля качества в  DRM..."  –1 +/
Сообщение от Анонимм (??), 27-Фев-17, 18:30 
> Для ядра в user space есть архитектура "um", и еще конечно qemu,

Проброс железки "внутрь" - задача может и простая, но не решает поставленный вопрос:
тестировать модуль этой железки (который просто будет бежать внутри um/qemu)

> так что первые 2 пункта и для Linux есть том же относительно
> готовом виде.

Попробуйте пробросить что-нить эдакое в qemu или найти тот же драйвер, если конфигурите ядро под ARCH=um. Да, его там просто может не быть (т.к. драйвер может зависеть от конкретного множества аппаратных архитектур). Т.е. решение - не универсально.


> Блин, почитайте про юнит тесты и multithreading,

Готово. И?
"Трудно == не надо делать"?

> а прерывания (которые используют практически любая железка)
> дают тот же эфект внезапного переключения контекста,
> все еще думаете что это легко написать тест который реально что-то тестирует?

Покажите мне где я упоминал слово "легко".

Ответить | Правка | Наверх | Cообщить модератору

346. "Линус Торвальдс выступил с критикой контроля качества в  DRM..."  +1 +/
Сообщение от не такойemail (?), 28-Фев-17, 03:14 
>> Для ядра в user space есть архитектура "um", и еще конечно qemu,
> Проброс железки "внутрь" - задача может и простая, но не решает поставленный
> вопрос:
> тестировать модуль этой железки (который просто будет бежать внутри um/qemu)
>> так что первые 2 пункта и для Linux есть том же относительно
>> готовом виде.
> Попробуйте пробросить что-нить эдакое в qemu или найти тот же драйвер, если
> конфигурите ядро под ARCH=um. Да, его там просто может не быть
> (т.к. драйвер может зависеть от конкретного множества аппаратных архитектур). Т.е. решение
> - не универсально.

Что-то вы оба отдаляетесь от контекста обсуждения:

о том насколько легко разработчику драйвера написать тесты в Linux vs мифическая микроядерная ОС.

ИМХО, микроядерная ОС ничем не поможет,
и в том и в другом случае есть довольно небольшой API между драйвером и ОС.
Т.к. хотя ядро Linux это и монолит, но это не значит что как программа оно плохо
спроектировано, модульность и инкапсуляция там везде применяются.

То в каком адресном пространстве будет запускаться тест совершенно не скажется на том, просто будет тест написать или нет.

И с современными технологиями виртуализации и возможности отладки теста будут одинаковы.

А вот сторону эмулирующее микроядро и сервисы и железо vs ядро и железо надо будет писать в обоих случаях. Потому что какой это нафиг юнит тест, если для его запуска нужно запустить всю остальную программу, это уже функциональный тест получается.

Ответить | Правка | Наверх | Cообщить модератору

364. "Линус Торвальдс выступил с критикой контроля качества в  DRM..."  +/
Сообщение от Анонимм (??), 28-Фев-17, 11:52 
> ИМХО, микроядерная ОС ничем не поможет,
> и в том и в другом случае есть довольно небольшой API между
> драйвером и ОС.

Да, согласен.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру