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

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

Меня тоже раздражает отсутствие нормально обработки нехватки денег в городе, элоектроэнергии в деревне и воздуха в космосе.

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

Да всем бы такого «плохого тестирования», как ядру. Не спорю, косяков у них хватает. Но нерабочие релизы ещё не выкатывали.

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

Более распостранено, чем даже микрокод всяких интелов. Думаю не слишком громко.

Где там результаты сборок под mips?

Ждём автоматическое ядро.

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

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

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

Антипрививочники на моем ЛОРе.

нерабочие релизы ещё не выкатывали

Выкатывали. Через день выкатывали фикс.

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

Вы что, хотите, чтобы как в венде?

Лучше бы они опциональную автоприбивалку течных приложений прикрутили.

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

На электрон же, ну!

Что значит опциональную? Она и сейчас опциональна - то прибивает, то не прибивает.

все эти годы ядро демонстрировало удивительную надежность

Ещё бы, его проектировали профессионалы.

Но времена меняются,

Да, в индустрию приходят смузихлёбы, инклюзивность, все дела.

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

Да, потому что макакокодеры не осиливают в качество работы старичков

решение зрело давно.

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

Пруф

Присоединяюсь, где пруфы, уважаемый?!

Вы что, хотите, чтобы как в венде?

Если бы, в винде надо всё равно перезагружаться, после установки драйверов. Насколько я слышал, даже в вин10 этого не победили.

OOM killer прекрасно срабатывает. Просто те, кто жалуются
на отсутствие киллера, не доводят дело до серьезного OOM.

Ага, т.е. вы предлагаете постоянно ожидать всё это время от начала неработоспособности системы, до полного засирания памяти впритык?!

Любое, пусть и убого выглядещее решение, если оно реально будет решением и разруливать эту проблему, будет лучше, даже если это мегакостыль!

Антипрививочники на моем ЛОРе.

И этот человек, у которого подобное в голове всплывает, благодаря комментам, мало того, он такое ещё и пишет, заикается об адекватности?!

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

Опциональную, это значит не сама, а даёт выбор прибивать или нет, а сейчас по автоматом ничего не прибивается, ничего не предлагает, просто течёт и встаёт колом!

Юзерспейсные киллеры же уже запилили.

Инициатива исходила как раз таки от старичков. Чем лучше ПО покрывается тестами, тем надежней в итоге результат, это все понимают.

Russell Currey

«[В отличие от проекта, основанного исключительно на GitHub или GitLab], в котором pull equest содержит всю информацию, необходимую для слияния группы изменений, электронное письмо, содержащее, скажем, патч 7/10, не имеет этого контекста. Исходя из сообщения электронной почты практически невозможно определить была ли серия исправлений объединена, отклонена или заменена. В общем, списки рассылки просто не содержат метаданных того же уровня, что и современные сайты, на которых размещаются проекты, и это усложняет проблему CI [Continuous Integration]. "

Greg Kroah-Hartman, мейнтейнер стабильной ветки Linux

«Linux работает повсюду и на очень многих различных аппаратных средствах, но тестирование на этом оборудовании было очень минимальным. Большинство людей просто тестировали на тех немногих вещах, которые им небезразличны. Поэтому мы хотим тестировать ядро на максимально широком спектре оборудования чтобы убедиться, что мы на самом деле поддерживаем все оборудование, которое, как мы утверждаем, мы поддерживаем »

Бредовая аналогия с динозаврами как аргумент

Лор классический, бредосодержащий.

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

С Грегом согласен, если бы его слова подтверждались практикой, а не стали, модными сейчас, громкими лозунгами, было бы замечательно!

Я тоже немного опешил от увиденного, потом вспомнил, что это ЛОР и вовремя посмотрел на автора поста, вроде отлегло.

@mittorn сделал акцент на интерактивности

Мне на мой пост ответили 4 человека. Твой оказался самым бесполезным. Что сказать-то хотел? :)

Мысль проста, как мычание. Если памяти не хватает, то никакой «нормальной» обработкой эту проблему не решить. Нужно или оптимизировать ПО, или добавлять память или (возможно) какими-то административными мерами исключить ситуации, приводящие к ее нехватке. А то развелось школоты. Вы еще «нормально» недостаток места на диске обработайте. Фильм-то скачался, а писать некуда, или вовсе отсутствие компьютера обработайте, факиры недоделанные...

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

Модули уже давно есть, и большую часть драйверов можно собирать как модули.

Если памяти не хватает, то никакой «нормальной» обработкой эту проблему не решить

Завершение наименее нужного процесса - это и есть нормальная обработка. Но ядерный киллер не делает даже этого.

И сравнение с выкидыванием из самолета неуместно. Это скорее похоже на потрю хвоста ящерицей, ибо убитый процесс может быть перезапущен.

Если процесс не нужен, не нужно его и запускать. А если нужен, то его убийство в общем случае может стать фатальным.

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

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

не нужен

Плеер или вкладка в браузере менее важна, чем иксы или pppd.

по определению информации от юзерспейса должно быть минимум

OOM score там как раз уже есть, но он не особо работает.

Плеер или вкладка в браузере менее важна, чем иксы или pppd.

Трудно сказать. И плейер и вкладка в браузере может быть смыслом работы всего компьютера. В ней может идти процесс, ради которого весь этот комп купили и запустили. А pppd может и вовсе не нужен.

Простой пример. У меня телефон 8 ядер, 4 гига оперативы и все такое. Запускаю песню. При переходе с портрета на ландшафт и обратно звук хрипит и заикается. А должно хрипеть все остальное, кроме звука! А оно наоборот, прекрасно работает, хотя мне нужен только звук, который как раз хрипит из за того,что все остальное летает...

OOM score там как раз уже есть, но он не особо работает.

Поэтому и не работает, что информации для его вычисления на этом уровне нет и быть не может.

Трудно сказать.

Лучше делать хоть что-то, чем вешать всю систему.

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

В юзерспейсе пока ядро колом это может повиснуть. Надо на уровне ядра резервировать память под определённые процессы. Запасные 50 мегабайт которые смогут использовать только иксы и диалог исправят проблему. Разумеется не zenity, а специально написанное приложение. Так же нужна возмодность запретить уходить в swap определённым процессам. Этого тоже нет.

Если процесс не нужен, не нужно его и запускать.

Он может стать ненужен, потому что стал течь, если все процессы из-за него встали колом, о какой дальнейшей работе, пусть даже, изначально нужных процессов, может идти речь?

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

А при переполнении какой смысл от этой псевдоработы, если ничего толком не работает, пусть даже и твой нужный процесс всё повесил, его не осталвлять надо, а прибить и разбираться, что это было такое!

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

Такой интерфейс уже есть.

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

Вы не поверите - /proc/<PID>/oom_score_adj В ненавистном systemd - из коробки.

У меня есть друзья одеты в кожу и мы ставим друг другу линуууууукс. Как я обожаю линукс!

nice, ionice, cgroups, oom_score_adj ...? Андроид научился на базе всего этого хозяйства вести себя прилично, но десктоп и сервера это другое. Не готов к плотной дискуссии на эту тему, но на вскидку есть ощущение, что нужны дополнительные механизмы. Но таки да, запрос должны формировать юзерспейсные девелоперы, а они не делают даже того, что делает тот же андроид. Ну а на нет и ничего нет. Все что было нужно тому же андроиду в ядро вошло, так что если даже чего-то сейчас не хватает это вопрос преодолимый, как показывает практика.

И системдэ тут при том, что...?

Системд позволяет задать adj для всего юнита, а не бегать за отдельными пидами.

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

Но таки да, запрос должны формировать юзерспейсные девелоперы, а они не делают даже того, что делает тот же андроид.

А что делает андроид, если не секрет?

юзерспейсные девелоперы, а они не делают даже того, что делает тот же андроид

На демо https://youtu.be/PLVWgNrVNlc мы пытаемся повесить систему бесконечным открытием вкладок браузера, но ничего не выходит. Что еще должны делать девелоперы?

нужны дополнительные механизмы

Есть PSI и /proc/meminfo, этого полностью достаточно для успешного киллинга жиробасов вовремя.

По ссылке только общие фразы. Какова будет архитектура этой CI? Сможет ли разраб в урюпинске настроить свою тестовую ноду, имея железо для конкретной платформы, или все билды будут ломиться в один толстый тестовый хаб?

А что делает андроид, если не секрет?

https://developer.android.com/guide/components/processes-and-threads.html

Что еще должны делать девелоперы?

Ну например. Я, как десктоп юзер, хотел бы иметь возможность «закрепить» наиболее важные для меня процессы ( браузер целиком, страницы браузера, IDE, етц). И\или хотел бы получать предложение закрыть какие-то программы из списка в случае приближения ООМ апокалипсиса. Хотел бы иметь возможность вручную регулировать IO приоритеты. Назначать предустановленные приоритеты различному ПО, до запуска. И прочая и прочая. Да, чисто технически я могу и сейчас гаечки подкрутить. Если на то пошло я могу и хтмл глазами парсить. Но что-то не хочется.

https://kernelci.org/faq/