LINUX.ORG.RU

Ужесточение правил заморозки кода ядра

 , ,


0

0

Существующие уже давно правила заморозки кода при разработке ядра Linux разрешают выполнять вливание существенных изменений в основную ветку только до выхода первого релиз-кандидата новой версии (RC1), после чего в основную ветку должны приниматься только исправления серьезных ошибок. Однако на практике эти правила зачастую игнорировались, и даже после выхода RC1 и RC2 в ядро принимались не только исправления ошибок, но и улучшения функционала. Такой подход практиковался вплоть до недавнего времени, в частности, именно так готовился 2.6.35-rc2. Однако непосредственно перед выходом второго релиз-кандидата 2.6.35 Торвальдс неожиданно начал жестко отказывать в просьбах ввести в основную ветку ядра не связанные с исправлением ошибок изменения.

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

Новость взята на OpenNet

>>> Подробности

★★★

Проверено: Shaman007 ()
Ответ на: комментарий от wxw

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

Кто после этого скажет, что микроядро не нужно?

И чем же микроядро поможет?

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

Если не лениться и переписать весь код на Ada, а не чёрт знает что, то код становится значительно понятнее даже без знания контекста. ;)

*fixed.

splinter ★★★★★
()

Линус тоже человек! пущай отдохнёт.

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

wxw> Кто после этого скажет, что микроядро не нужно?

А смысл, если патч всю подсистему убивает?

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

anonymous> Ты хоть пробовал для Сибиана разрабатывать?

И при чём тут микроядерность?

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

Левый драйвер х.з. каким образом перезаписывает рандомную область памяти монолитного ядра и крошит систему. Классика

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

> И теперь ждать драйверов на железку xyz не в следующем, а через релиз?

Нормальные производители сопровождают железки дровами, а нормальные покупатели убеждаются что дрова есть перед покупкой. А не тролят на тему «Линус/Гейтс/Джобс козлы потому что не поддерживают мою железку»

FeyFre ★★★★
()
Ответ на: комментарий от MuZHiK-2

Сосед Торвальдса детектед :)

>Ну вообще-то там не просто так он ушел в отпуск, а потому что у него дети закончили очередной год в школе и у них каникулы. Жена сказала быть дома с детьми хоть немного, а с ней уж не поспоришь.

tensai_cirno ★★★★★
()

Одной из основных причин, побудивших Торвальдса на такие действия, он называет ужесточение правил в отношении пользователей на сайте linux.org.ru.

b_b_b
()

Ну и правильно. Хватит уже быдлокодить.

Doctor_Drive
()

Надо возвращать старую схему со стабильной и нестабильной ветками

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

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

Кто после этого скажет, что микроядро не нужно?

И чем же микроядро поможет?

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

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

ага, а интерфейс между микроядром и модулями был бы прост и интуитивно понятен :)

drakmail ★★★★
()

Правильно! Давно пора!

fidaj
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.