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

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

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

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

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

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

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

Вакансия «Buttplug test unit».

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

в 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. Как вообще может сторонний разработчик утверждать что железо работает правильно, тем более многие драйверы написаны в итоге реверса закрытого кода ? Тут только длительное использование на реальных задачах.

Не совсем то, но всё же: https://www.opennet.ru/opennews/art.shtml?num=55543

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

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

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

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

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

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

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

Авто-тестами в линуксе являются 1% пользователей десктопа.

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

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

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

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

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

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

А вы хотя бы погуглили сначала, прежде чем на лорчик писать?

Вот например для юнит-тестов уже что-то придумали:

https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html

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

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

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

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

Сиди на железках, на которых сидят разрабы. И проблем не будет.

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

Будет работать то, что поддерживается нормальными дистрибами.

https://certification.ubuntu.com/desktop

https://catalog.redhat.com/hardware/workstations/search

Самое близкое, что я знаю, это LTP (linux-test-project.github.io).

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

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

Тебя взломали?

Второй раз за день вижу, что «толстишь».

Нет, это моё нормальное, расслабленное состояние. :D

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

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

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

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

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

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

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

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

Как и любого другого софта.

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

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

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

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

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

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

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

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

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

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

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

https://www.opennet.ru/opennews/art.shtml?num=55596

О, кто то еще допер.

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

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