Ядро Linux получает автоматическое тестирование : KernelCI

У Linux, самой важной программы в мире

Не слишком ли громко сказано?

Шелдон, залогинься.

Отлично. Интересно сколько там полный тест по времени занимает.

надебсь, поможет. Ядро сейчас это абздец какой-то

что не так? меня лично раздражает отсутствие нормальной обработки нехватки ОП

А что с ним не так сейчас, помимо плохого CI-тестирования?

что сломалось на древнем устройстве, смогут выявить?

Вряд ли это поможет с индусскими драйверами или с багофичами вроде повисания при oom/записи на флэшку.

Потому что основные проблемы в общей архитектуре кода.

пока все же оно не дотягивает до уровня божественного ядра реактос

Sad but true. По хорошему надо выкинуть нафик и переписать с нуля...

Не зря гугель пилит саою фуксию.

Гугель же сказал, что фуксия - просто research песочница новых идей перед их переносом на суровый продуктовый линукс.

А есть ли подобное для archlinux и systemd?

Вообще, отдельные команды вроде Intel-DRM уже давно тестируют свою разработческую ветку перед мерджем в апстрим, тут смысл скорее в централизации CI для отлова багов на уровне мерджа в mainline.

чо толька не предумуют лишь бы не переписывать все на Руст

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

видел на одной странице :)

Посмотрим, как оно обернётся.

и на скольки платформах гоняют. и собсно как, эмулятором?

Для systemd разумеется есть.

Недавно столкнулся с багом в systemd-networkd как раз под arch в контейнере. Не создавал указанные маршруты. Сейчас обновил - как ни странно, всё работает нормально.

Это в том числе. Ну и куча случаев когда ядро загибается без причины. Например, пару дней назад переключил виртуальную консоль в графический режим процессом который был под отладчиком. Процесс прибил, консоль осталось в графическом режиме. после этого все попытки сделать chvt просто зависают намертво. То есть все случаи когда у меня зависали иксы намертво и не переключалась консоль были не из-за зависания графической системы, а из-за какого-то тупого косяка ломающего chvt.
А так - локапы в ядре можно перечислять вечно. Завис gpu? все процессы которые обращались к нему висят и не реагируют на sigkill. Можно было в конце концов прибить их. Зависло одно из ядер cpu? тоже висим. Других нет чтоль? зачем вообще весить систему при rcu stall? В последнем случае sysrq работает, но не работают даже таймеры, из-за чего на sysrq+o даже не реагирует.
TMM - менеджер памяти DRM тоже колом всё ставит при ошибке. Короче обработка ошибок сводится к тому что повесить всё намертво. Зачем она тогда?

дедлоки

Стоп, все это время не было?

Пруф

Linux — самая популярная программа в мире.

Intel-DRM

Was? DRM? Feuer!

Реакция здорового человека :)

https://ru.wikipedia.org/wiki/Direct_Rendering_Infrastructure

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

Как вот это:

Теперь, на Open Source Summit Europe в Лионе (Франция), KernelCI стал проектом Linux Foundation.

Обещает вот это:

Ядро Linux получает автоматическое тестирование : KernelCI

Аминь, держать всю лабуду в ядре — бред

Самое забавно в этой новости то, что оказывается раньше автоматического тестирования не было.

Ну всё. Linux Foundation Microsoft начинает кампанию по полномасштабному загаживанию ядра. Готовьтесь к ужасной сырости, тоннам дыр и всё это приправленно соусом «прогрессивной» автоматизации тестирования и поддержкой масс-медиа.

Интересно, Линус в следующем году уйдет на пенсию? Или он согласился принять всё дерьмо на себя за определённую сумму денег?

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

меня лично раздражает отсутствие нормальной обработки нехватки ОП

Используй юзерспейсный патч для ядра - earlyoom

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

Напомни, как там получилось с современными средствами обеспечения надежности в ВИН10? Или что стало с автоматизированным проектированием х86 процессоров?

Улучшать и совершенствовать процесс разработки и тестирования, бесспорно нужно.

Но когда эта инициатива исходит от печально известного Linux Foundation, а не от самих разработчиков. Когда вместо серьёзного продуманного решения и интеграции навязывают какой-то копроративный ЙОБА-продукт.. Ничего кроме развала и впихивания зондов под прикрытием аппеляции к авторитету программы/принятой системы, я не ожидаю. Тем более что 2020ый год на носу, когда копрорации будут всеми силами лочить и отжимать ПК рынок. Безопасники ещё не оправились, не решили проблемы выявленные историей с хардварными бекдорами. А тут Linux Foundation новые бюрократические положняки пихают, которые создадут в разы больше проблем.

меня лично раздражает отсутствие нормальной обработки нехватки ОП

Это бай дизайн:

 *  The routines in this file are used to kill a process when
 *  we're seriously out of memory. This gets called from __alloc_pages()
 *  in mm/page_alloc.c when we really run out of memory.

https://github.com/torvalds/linux/blob/master/mm/oom_kill.c

seriously out of memory

Нехватка памяти в юзерспейсе - это еще не seriously. Ядро не считает нужным обрабатывать «несерьезные» OOM.

Да, бай дизайн сломали то что раньше замечательно работало.

А потом недавно в сисямдэ костыли-подпорки этой самой проблемы появились.

Совпадение? ...

Ядро сейчас это абздец какой-то

Сейчас ядро лучше, чем когда-либо за всю историю человечества. Не нравится 5.3 - используй Linux 0.1, если любишь ретро. Или когда оно, по-твоему, было хорошим?

Да, бай дизайн сломали то что раньше замечательно работало.

oom_kill.c особо не менялось. Да и не ломалось ничего: при запуске

tail /dev/zero

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

Лион, Лиссабон... Чому не Воронеж?

одной из самых горячих тем было то, как улучшить и автоматизировать тестирование ядра Linux

«одной из самых горячих тем было улучшение и автоматизирование тестирования ядра Linux»

Так не лучше будет?

И тире вместо двоеточия в заголовке.

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

Кек, драйвера пишут корпорации, но тестируют на машинах разработчиков? Отсыпь.

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

Ваша заявка принята: https://github.com/hakavlad/nohang/issues/58

Проблемы с этим:

1. Вывод окна с диалогом в новом процессе. Zenity жрёт 50 метров памяти, остальные диалоги не столь удобны

2. Что наиболее важно: как и какие процессы заморозить, чтоб память дальше не уменьшалась, пока юзер думает кого убить. SIGKILL не так уж безобиден, некоторые из него некорректно просыпаются.

Но в целом задаща не сложная. Но это будет сыро и костыльно выглядеть.

SIGKILL

SIGSTOP конечно. Поправил.

Linux — самая популярная программа в мире.

Возможно, но точно не самая важная.

То же самое теперь и с X.org. Решили, что будут писать тесты и по-старому каждые полгода будут релизиться. Тесты пройдены — вперед.

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

если бы у бабушки был член - она была бы дедушкой.
создай коль такой умный, этож опенсорц.

эт как? Система сама будет собирать всю инфу и отправлять «куда следует» (или и куда не следует)? А там ещё и Лёня со своей раковой опухолью, метастазы от которой уже по всей системе. Ну чо.. Добро пожаловать в мир Шиндовс.

ЗЫ. Да - я параноик. Но если у вас паранойя это не значит что за вами не следят