LINUX.ORG.RU

Вопрос риторический по автотестам и ядру

 , ,


0

1

Не разраб ядра ни разу, задался вопросом, а в дровах в ядре при принятии изменений кто то следит за наличием автотестов? Бывают ли автотесты, которые бы юзер модуля мог запустить у себя и проверить, что железка пашет правильно? (это позволило бы сделать софт для дистра, который бы можно было пускать локально и проверять, что линь пашет на конкретной железке правильно и слать отчет «мы правильно пашем на мульене железа!»). Этот зоопарк железок и дров к ним как поддерживается в консистентном состоянии кроме честного пионерского слова автора и ревьюера?

Я конечно всего кода ядра не видел, но в драйверах не замечал практики отдельного добавления автотестов.

Как правило, в probe устройства на каждом этапе инициализации делается проверка успешности операции по коду возврата. Ошибочный код - драйвер сообщает в системный журнал и прекращает деятельность по настройке конкретного экземпляра устройства.

проверить, что железка пашет правильно?

Сложная железка может иметь self-test. А так, загрузил драйвер, смотришь, как там дело пошло. Изображение и звук есть? Данные передаются и принимаются с ожидаемой скоростью и BER? Ну значит всё хорошо.

А вообще правильно и полностью тестировать аппаратуру и ПО к нему - задача производителя.

apt_install_lrzsz ()

Вот мне интересно, в проекте buttplug есть автотесты? Там же ж сложная инфраструктура, и ядро, и юзерспейс. Как тестировать?

Benis ()
Ответ на: комментарий от Benis

Да так же, как и везде, я думаю. Максимально полно описывают тесткейсы. Готовят аппаратуру, собирают стенд. Поэтапно проводят тест по каждому кейсу. Заполняют списки проверки. Пишут итоговый отчёт.

apt_install_lrzsz ()

а в дровах в ядре при принятии изменений кто то следит за наличием автотестов?

в v4l2 следят

● New drivers must pass the compliance tests.
● Close to 900 tests are performed.

http://events17.linuxfoundation.org/sites/events/files/slides/v4l2-testing.pdf

но это не совсем то что ты хочешь - v4l2-compliance тестирует драйвер на совместимость с API v4l2. Как вообще может сторонний разработчик утверждать что железо работает правильно, тем более многие драйверы написаны в итоге реверса закрытого кода ? Тут только длительное использование на реальных задачах.

spbob ()

Ок,понятно, что автотестирование сюда еще не добралось, хотя бы юнит. Судя по всему. Там видать поле не паханое…или не нужное, фиг знает. За инфу всем спасибо!

i3draven ()
Ответ на: комментарий от shell-script

Да, примерно это. Только хотелось бы что бы авторы дров такие штуки просто писали «потому, что что бы в ядро что бы приняли такое положено». Типа метод isAwailable(hwId) и isWork(hwId) что бы можно было универсальную систему оценки работоспособности ядра создать и потом просто вызвал такие методы со списком pciId он все проверил, результ слил в телеметрию централизованную, разрабы подивились, допилили.

i3draven ()

вообще можно и нужно, но это ленятся делать.

Приведу пример: для SDI карты захвата/отдачи вполне можно и нужно делать тесты, которые подают сигнал и принимают его.

Нет никаких причин не иметь такие тесты от авторов драйверов, но особо не видать. Возможно они редко покидают границы компании, разрабатывающей эти драйвера.

max_lapshin ★★★ ()

Конечно же нет.

Тесты для драйверов затруднены необходимостью физического взаимодействия с железом.

Harald ★★★★★ ()

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

pahafema ()
Ответ на: комментарий от max_lapshin

Приведу пример: для SDI карты захвата/отдачи вполне можно и нужно делать тесты, которые подают сигнал и принимают его.

у них у всех есть встроенный pattern generator чтобы как-то автоматизировать ?

Нет никаких причин не иметь такие тесты от авторов драйверов, но особо не видать

есть не автоматические тесты

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842396/Xilinx V4L2 SD...

spbob ()
Ответ на: комментарий от seiken

Вопрос состоял не в том что бы найти технический инструмент скорее…для юнит тестирования ничего особенного не нужно, можно и не применять, и написать на голом языке. Вопрос, как в топике описано, состоял в том что бы выяснить есть ли такая практика и обязательно ли это, и пишут ли такое.

Как выяснилось, не пишут и не обязательно, и тестов нет. Во всяком случае как я понял. То есть инфраструктуры и методологии поддержания консистентности кода сейчас в разработке ядра не применяется. Что меня лично удивило. Потрясающе как может такая куча кода работать нормально…и понятно почему не работает.

Но за ссылку спасибо конечно.

i3draven ()
Ответ на: комментарий от i3draven

Надо писать в Спортлото или куда там пишут разрабам ядра, что они все неправильно делают? :)

i3draven ()
Ответ на: комментарий от pisqotron5000

Да, придется видимо так и делать :) Собираюсь вот ноут брать новый, моему десять лет и в нем все еще вайфай модуль от интела плохо работает. Новый ноут будет с свежим железом и работать не будет опять все :)

i3draven ()
Ответ на: комментарий от i3draven

Ну, тут же как с туалетами. Вот есть общественный и бесплатный, а есть частный и за плату. В каком будет чище? А тут туалет виртуальный и распределенной. И поскольку к каждому толчку по Сталину не приставить, где-то обязательно насрут мимо, где-то труба забьется, и т.д.

Вобщем, если тебе надо Q/A твоего кода обечпечивать, то ты этим и занимайся. А если код не твой, то никто тебе не должен.

seiken ★★★★★ ()
Ответ на: комментарий от xaizek

Да, вот примерно так, только при ревью это должно быть обязательным условием для приема кода в ядро «покрыто тестами на 100%». Как в других проектах давно уже. Интересно, что хватает обычного «мейнтейнер сказал можно»…но я практически не знаю как там разработка идет и потому спросил вопрос. Тогда все сторонние попытки «покрыть тестами вечно уходящее из под ног и растущее ядро сторонними чуваками» не нужны будут, а покрытие будет качественным. Непонятно почему Линус еще не заставил всех покрывать код тестами. Хотя бы новый код покрывать.

i3draven ()
Последнее исправление: i3draven (всего исправлений: 2)
Ответ на: комментарий от i3draven

обязательным условием для приема кода в ядро «покрыто тестами на 100%».

Признайся честно, ты троллишь или больших проектов не видел?

seiken ★★★★★ ()
Ответ на: комментарий от Benis

Делириум, меня вот больше беспокоит, какие бюрократические особенности должна получить аппаратура теледильдоники. Там же наверняка и заключение какой-то организации должно быть, что девайс безопасен. Так что нужен целый ряд специалистов. Одним тестировщиком не обойтись...

peregrine ★★★★★ ()
Ответ на: комментарий от i3draven

обязательным условием для приема кода в ядро «покрыто тестами на 100%»

и «вот трекинг-номер посылки с железкой»

pahafema ()

Как ты себе представляешь, к примеру, автоматическое тестирование драйвера видеокарты?

Harald ★★★★★ ()
Ответ на: комментарий от seiken

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

i3draven ()
Ответ на: комментарий от i3draven

В любой другой софт можно подавать входные значения и читать выходные чисто программно. С драйверами так не получится. Нужен либо специальный испытательный стенд, заточенный на конкретную железку, либо человек, который будет проверять результаты.

Harald ★★★★★ ()
Ответ на: комментарий от Harald

Думаю это дли примитивных железок так. В современном железе типа видеокарты давно уже встроенный отладчик есть и еще вагон всего. Но, я дрова на видюхи не писал, утверждать не могу о том насколько это все можно покрыть тестами. Спор считаю бессмысленным, как художник художнику.

i3draven ()
Ответ на: комментарий от i3draven

Какая современная видеокарта, умеет, к примеру, измерять обороты своего кулера? А? :) Как без этого автоматически протестировать, правильно ли драйвер его включает-выключает?

Harald ★★★★★ ()
Ответ на: комментарий от i3draven

Или драйвер вебкамеры. Ты ей свою рожу показываешь, а драйвер картинку вверх ногами отдаёт. Или цвета в пикселях перепутаны, и рожа у тебя сине-зелёная на выходе. Как проверить, соответствует ли изображение оригиналу и как передать на вход эталонное изображение?

Harald ★★★★★ ()

В ядре нет автотестов, никто ни за чем не следит и даже честное пионерское не даёт. По слухам там порой некомпилирующиеся патчи проходят ревью, но ссылок не дам.

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Harald

Да, вероятно тестами покрыть можно не все, а значительную часть. Это не значит, что их не стоит делать :) Что ты уперся как дите :)

i3draven ()
Ответ на: комментарий от i3draven

Скорее наоборот, значительную часть функциональности покрыть тестами нельзя. Без дополнительного оборудования.

Harald ★★★★★ ()

На уровне ядра нет.

Этот зоопарк железок и дров к ним как поддерживается в консистентном состоянии кроме честного пионерского слова автора и ревьюера?

Не поддерживается. Но вообще, выпустить косое железо с полностью нерабочими дровами под него, на это даже бойцы дядюшки Ляо не отваживаются. Они, хоть и бесконечно «смелые», но не бесконечно же тупые. Хотя, у них своих приколов больше чем достаточно. Есть такое.

На практике, при разработке соответствующего железа, всё это отрабатывается на уровне тестов внутри компании. В паблик идёт только то, что нужно именно в паблике. И с тестами там ни кто и разбираться не будет.

Moisha_Liberman ★★ ()
Ответ на: комментарий от i3draven

как нужно быть так увлеченным собственной идеей про автотесты железа, что прочитать целую статью про CVE в ядре и не заметить, что они не связаны? пц.

t184256 ★★★★★ ()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от t184256

Идея про автотесты в целом, а железо это просто применение идеи. Да и не идея это, а вопрос был, есть ли они в ядре.

i3draven ()
Последнее исправление: i3draven (всего исправлений: 1)
Ограничение на отправку комментариев: только для зарегистрированных пользователей