Честно говоря это та точка, где трагедия превратилась в фарс. То что это сделано с ведения Линуса и так понятно с самого начала.
Но назвать несколько "независимых" (а их кстати говоря осталось очень и очень мало, все текущие большие мантейнеры аффилированы с одной из крупных корпораций) мантэйнеров "фабрикой" троллей...
Я бы не захотел бы связываться с фабрикой троллей, которая способна добиться хотя бы малого статуса мантейнера в количестве нескольких штук ради того, чтобы потролить Линуса.
Нихрена ж себе, пардон муа франсе. Я думал, он умнее.
С другой стороны маски сброшены, что мешало сразу написать так с самого начала ?
Perhaps one of the more surprising changes in the 6.12-rc4 development kernel was the removal of several entries from the kernel's MAINTAINERS file. The patch performing the removal was sent (by Greg Kroah-Hartman) only to the patches@lists.linux.dev mailing list; the change was included in a char-misc drivers pull request with no particular mention.
The explanation for the removal is simply "various compliance requirements". Given that the developers involved all appear to be of Russian origin, it is not too hard to imagine what sort of compliance is involved here. There has, however, been no public posting of the policy that required the removal of these entries.
Там уже не получилось замять, здесь вопрос скорее не в этом, т.е. "Не почему?" это сделано (там в листах написали впрямую "It's not difficult to deduce what the "various compliance requirements" are and I'm sure Greg is aware of this." и прочее), а почему это сделанно именно так ?
почему это сделано в обход прописанных и принятых процедур ?
почему Грег нарушает принятый CoC и пытается ответить на вопросы приватно ?
почему он ссылается на некие "various compliance requirements" которые нигде не описаны ?
что дальше ждать от "various compliance requirements" ?
является ли разработка ядра по-прежнему "открытой" и "свободной" как это заявлено в постулатах ?
Если удалят упоминания, то значит все слова об открытых лицензиях были пустым звуком
Чисто технически, такая возможность имеет место быть - могут сделать как это было в момент перехода где-то с 2.5 на 2.6 (тогда историю начали заново - ничего правда при этом не удаляли).
Но это всего лишь значит, что упоминания и истории не будет на официальных зеркалах. Так то история помнит.
No, no, no. Nuh, uh. Greg has unfortunately decided to respond in private over a matter that by no means should be glossed over. Here below is our conversation:
В ответе содержится следующее (в оригинальном письме съехало форматирование:
Sorry, but that's not how this is allowed to work. Please contact your company lawyers if you have any questions about this. And this only affects maintainers, as you aren't listed in the MAINTAINERS file, there should not be any issue, but again, contact your company if you have any questions as they know what is going on. Just *wink* if you were compelled into this.
An absolutely no-one-ever-reviewed patch, not even by the maintainers who got removed themselves - at least not on the mailing list. Then the patch just got slipped into an unrelated subsystem pull request, and got pulled by Torvalds with not even a comment.
What about the next time? Who next would be removed from the MAINTAINERS file, the kernel.org infrastructure? What if the compliance requires another XZ backdoor to be developed without further explanation? Is the kernel development process still done in public?
Are the "compliance requirements" documented on docs.kernel.org? Who are responsible for them? Are all that are responsible employees of The Linux Foundation, which is regulated by the U.S. legislature?
Первое этот патч запихнули в обход всех принятых процедур на фактически технический листинг:
Archive-only list for patches patches@lists.linux.dev m: subscribers and/or posts to the list are moderated (фактически он закрыт для "посторонних" людей)
В копии стоит только Грег, хотя в копии должны быть удаленные люди, листы подсистем и открытый листинг linux-kernel@vger.kernel.org.
Само письмо отправлено 2024-10-18 11:31
И вуаля патч был применен на ветку уже 2024-10-18 13:40:03 +0200.
Второе, согласно традиции, из MAINTAINERS перемещаются в CREDITS, что тоже не было сделано.
Под самим письмом вопросы от Geert (уже упомянут), и от Wolfram Sang, который является мантэйнером I2C SUBSYSTEM (помимо прочих драйверов):
It's not difficult to deduce what the "various compliance requirements" are and I'm sure Greg is aware of this. The Linux Foundation, if interested in continuing their governance role over the Linux kernel, should be ready to explain themselves over this decision. Greg and Linus, I'm not sure if I'm ready to believe that this is supposed to be a political show - but if this is the case, please leave the ground for the Foundation - they should be the one responsible and receiving the scrutiny (or insult, as I'm sure many - myself included - find this patch insulting).
So I repeat - call the decision-makers out and ask for their explanation.
@denis-19мне кажется ответ от Mingcong Bai стоит добавить в пост.
Второй - NVME драйвера, который тоже POC для дипломной бакалавра, нежели контрибуция в ядро.
Если я правильно помню, то это не драйвер, а обвязка, которая позволит создать драйвер. Если это действительно так - то это подпадает под общее правило "улучшений которые никто не использует".
Опять же смотрим https://lwn.net/Articles/987140/ - это улучшения И ДРАЙВЕР которые их использует - так можно, абстрактную инфраструктуру, которая не используется - нельзя (что не жаль и логично).
Ну и третий - драйвер для графики для яблочных устройств, который Асахи сама же реверсила и сама же писала для своего яблочного линукса. Тут, если читали сами мэйлисты, то должны быть в курсе, что "и так сойдёт" в качестве аргумента к NAK на третий раз уже не вызывает желания пытаться прислать исправленные патчи ибо любые аргументы начинают игнорироваться после того как Rust засветился в тексте.
Вынужден обвинить вас в излишней симпатии к этой девушке. Реально мы имеем мантейнера, который по правилам отвечает за всё на что он ставит reviewed-by тэг и человека который заявляет, что без этих исправлений в подсистеме драйвер не взлетит (ты то теперь взлетишь, а все остальные как ?), после чего привлекает армию людей никак не вовлеченных в разработку ядра для раскрутки хайпа. Ну такое себе...
Ваша точка зрения понятна, отчасти согласен - человеку не вовлеченному в разработку ядра может быть трудно объективно посмотреть со стороны.
Не очень понимаю связь между размерами бинарей и поддержкой SoC в ядре.
Банально нет места под ядро большего размера (памяти нет, флэша не хватает, старый загрузчик), они уже постепенно отмирают по этой причине (ядро всё таки растёт в размерах).
Внимательно прочитал, честно говоря не знаю как реагировать на это всё. В ядре можно найти много примеров дискуссий как в одну так и в другую сторону.
Но такие масштабные шоу на публику большая редкость.
In the end, Asahi Lina gave up on using the DRM scheduler at all; the plan now is to reimplement that functionality within the Rust code using workqueues instead.
При чём все это произошло УЖЕ на стадии RFC...
В итоге получается на счету, на данный момент, один НОВЫЙ драйвер (https://lwn.net/Articles/987140/), который человек не поленился и дотащил до победного конца.
Если посмотреть на ситуацию в целом (листы вполне можно стянуть полностью):
Сейчас струкутура поддержки кода линукса представляет собой несколько параллельных вотчин в каждом из которых есть некоторый свод неписанных правил, которым необходимо следовать как при использовании, так и при отправке патчей.
Ни разу не замечал, есть более строгие подсистемы например clk, pinctrl и dt, а есть, так скажем, более мягкие, где закрывают глаза на недочеты, но при этом в более мягких нельзя рассчитывать, что "и так сойдет".
Все санитайзеры работают в рантайме, что для большинства требует дополнительной инструментации кода при сборке. В случае c Rust - многие из проблем, который возможно задетектить при помощи этих инструментов резолвятся ещё на этапе компиляции - оно просто не соберётся, если ты не сможешь доказать корректность работы с памятью. Конечно не панацея, но если оно скомпилировалось, то с большой вероятностью проблем с памятью в этом коде нет.
Отчасти согласен, но вся эта прелесть конечно не снимает необходимость тестирования во время которого гарантировать отсутствия таких ошибок может например KSAN.
По идее не сильно больше чем будь оно на Си - код работает с no_std/no_main, так что код не должен раздуваться.
А вот это между прочим очень болезненный вопрос, который может исключить дальнейшее использование некоторых процессоров и SoC как например это происходит сейчас https://habr.com/ru/news/537100/.
А вот тут вынужден заметить (внимательно перечитав сопроводительное письмо), что о всех проблемах патча перечисленных Линусом, авторы патча "скромно умолчали", зато выкатили целую рекламную телегу, что "Rust это всегда хорошо !".
В таком случае в первую очередь пожалуйста примите мои извинения за поспешный вывод:
Поскольку видимо не в привычках автора, отвечать на вопросы, позволю себе некоторые ремарки:
Что касается вашего ответа:
Да, но в случае если идёт отладка отдельных компонент, например, Device Tree
На самом деле на практике получается, что одно и то же время, поскольку все равно компоненты каждый раз загружать заново. Во-вторых можно распаковывать FIT в память и менять, допустим, только Device Tree т.е. записывать его поверх распакованного, хотя с ядром или rootfs это уже будет нецелесообразно.
Сборка FIT из готовых компонентов это ничтожная часть времени от затраченной на сборку всех частей.
UPD:
Получается, что образы несжатые:
Image Type: ARM Linux Kernel Image (uncompressed)
Image Type: ARM Linux RAMDisk Image (uncompressed)
И кстати говоря
Loading Environment from FAT... *** Error - No Valid Environment Area found
U-Boot поддерживает чтение ENV в том числе из памяти с указанием адреса, т.е. вы можете загружать заранее сформированные ENV под различные ситуации - возможно это вам пригодится.
Поскольку видимо не в привычках автора, отвечать на вопросы, позволю себе некоторые ремарки:
Обычно эволючионный процесс разработки идет в обратную сторону, нежели описал автор - мы начинаем с загрузки файлов по JTAG и постепенно отказываемся от неё по следующим причинам:
загрузка может занимать колоссальное время от "Поковырялся в носу, попил кофе и забыл что делал" до "Два раза загрузил - рабочий день закончился";
по причинам выше мы не можем использовать нормальный rootfs, максимум маленький buildroot или даже просто busybox;
в любом случае нужна сеть, скопировать dmesg, log, perf data и прочее, это просто удобно;
Сжатые kernel и rootfs уже могут нам давать ускорение в несколько раз, замерить можно следующим образом:
инициализировать UART через OpenOCD (просто пишем всё, что необходимо, в соответсвующие регистры);
вывести привественную строку и начать загрузку компонентов;
померять время, например, с помощью grabserial;
Использование же FIT Image (https://docs.u-boot.org/en/latest/usage/fit/index.html) даёт нам некоторую независимость от жестко прописанных адресов в случае загрузки "по частям", тогда нам, в большинстве случаев, потребуются два жестких адреса - U-Boot SPL и адрес загруженного в память FIT Image.
Но, конечно, всё это не сравнится по скорости и удобству с загрузкой по сети и использовании корневой файловой системы поверх NFS, поэтому я рекомендую направить усилия именно в эту сторону, вплоть до использования SPI Ethernet модуля, если по каким то причинам нет возможности использовать полноценный контроллер.
И конечно всегда интересно посмотреть на замеры времени загрузки.
Да тут уже без разницы, тут под вопросом репутация Linux Foundation в целом уже.
Честно говоря это та точка, где трагедия превратилась в фарс. То что это сделано с ведения Линуса и так понятно с самого начала.
Но назвать несколько "независимых" (а их кстати говоря осталось очень и очень мало, все текущие большие мантейнеры аффилированы с одной из крупных корпораций) мантэйнеров "фабрикой" троллей...
Я бы не захотел бы связываться с фабрикой троллей, которая способна добиться хотя бы малого статуса мантейнера в количестве нескольких штук ради того, чтобы потролить Линуса.
С другой стороны маски сброшены, что мешало сразу написать так с самого начала ?
Небольшой апдейт от Jonathan Corbet:
https://lwn.net/Articles/995186/
Подтверждение моей информации и часть новой:
То есть коммит был протащен через https://lwn.net/ml/linux-kernel/ZxUH2J0BL3FCV6Hr@kroah.com/ - которая в принципе не имеет отношения к изменению файла MAINTAINERS, а является персональным репозиторием Грега.
Там уже не получилось замять, здесь вопрос скорее не в этом, т.е. "Не почему?" это сделано (там в листах написали впрямую "It's not difficult to deduce what the "various compliance requirements" are and I'm sure Greg is aware of this." и прочее), а почему это сделанно именно так ?
почему это сделано в обход прописанных и принятых процедур ?
почему Грег нарушает принятый CoC и пытается ответить на вопросы приватно ?
почему он ссылается на некие "various compliance requirements" которые нигде не описаны ?
что дальше ждать от "various compliance requirements" ?
является ли разработка ядра по-прежнему "открытой" и "свободной" как это заявлено в постулатах ?
Чисто технически, такая возможность имеет место быть - могут сделать как это было в момент перехода где-то с 2.5 на 2.6 (тогда историю начали заново - ничего правда при этом не удаляли).
Но это всего лишь значит, что упоминания и истории не будет на официальных зеркалах. Так то история помнит.
Спасибо! Я думаю полезно будет хотя бы некотрое время следить за веткой в мэйл листах.
Это абсолютно понятно, но даже больше чем это мне не понравился сам подход к проблеме со стороны Линуса и Грега.
Есть "официальный" ответ от Грега, который он похоже пытался выслать вне публичных листов (в этом суждении я доверяю Mingcong Bai):
https://lore.kernel.org/all/444fa53bdfdee75522a1af41655a99b0@aosc.io/
В ответе содержится следующее (в оригинальном письме съехало форматирование:
Так же был выслан revert-patch:
https://lore.kernel.org/all/20241023080935.2945-2-kexybiscuit@aosc.io/
Цитирую сообщение:
Первое этот патч запихнули в обход всех принятых процедур на фактически технический листинг:
В копии стоит только Грег, хотя в копии должны быть удаленные люди, листы подсистем и открытый листинг linux-kernel@vger.kernel.org.
Само письмо отправлено 2024-10-18 11:31
И вуаля патч был применен на ветку уже 2024-10-18 13:40:03 +0200.
Второе, согласно традиции, из MAINTAINERS перемещаются в CREDITS, что тоже не было сделано.
Под самим письмом вопросы от Geert (уже упомянут), и от Wolfram Sang, который является мантэйнером I2C SUBSYSTEM (помимо прочих драйверов):
То есть Грег с Линусом даже не попытались "сохранить лицо", а поступили по принципу "третьесортные недочеловеки" и так сожрут.
Эту "досадную оплошность" уже исправили:
https://lore.kernel.org/all/A74519B4332040FA+20241023063058.223139-1-wangyuli@uniontech.com/
Указав в копии письма, всех котого положено в данном случае (к сожалению WangYuli не является мантэйнером).
Под ковёр, конечно же, это всё замести уже (внезапно) не получилось:
https://lore.kernel.org/all/a08dc31ab773604d8f206ba005dc4c7a@aosc.io/
@denis-19мне кажется ответ от Mingcong Bai стоит добавить в пост.
Вопрос был к знатокам RUST, про технические трудности со строны RUST, а не про целесообразность как таковую.
Если я правильно помню, то это не драйвер, а обвязка, которая позволит создать драйвер. Если это действительно так - то это подпадает под общее правило "улучшений которые никто не использует".
Опять же смотрим https://lwn.net/Articles/987140/ - это улучшения И ДРАЙВЕР которые их использует - так можно, абстрактную инфраструктуру, которая не используется - нельзя (что не жаль и логично).
Вынужден обвинить вас в излишней симпатии к этой девушке. Реально мы имеем мантейнера, который по правилам отвечает за всё на что он ставит reviewed-by тэг и человека который заявляет, что без этих исправлений в подсистеме драйвер не взлетит (ты то теперь взлетишь, а все остальные как ?), после чего привлекает армию людей никак не вовлеченных в разработку ядра для раскрутки хайпа. Ну такое себе...
Ваша точка зрения понятна, отчасти согласен - человеку не вовлеченному в разработку ядра может быть трудно объективно посмотреть со стороны.
Банально нет места под ядро большего размера (памяти нет, флэша не хватает, старый загрузчик), они уже постепенно отмирают по этой причине (ядро всё таки растёт в размерах).
Внимательно прочитал, честно говоря не знаю как реагировать на это всё. В ядре можно найти много примеров дискуссий как в одну так и в другую сторону.
Но такие масштабные шоу на публику большая редкость.
При чём все это произошло УЖЕ на стадии RFC...
В итоге получается на счету, на данный момент, один НОВЫЙ драйвер (https://lwn.net/Articles/987140/), который человек не поленился и дотащил до победного конца.
Если посмотреть на ситуацию в целом (листы вполне можно стянуть полностью):
Получается, что с 2020 года:
1) Новых драйверов было предложено не более 10 (реально я насчитал меньше, но пусть будет так)
2) Большинство закачивает на стадии первого патча, даже не отвечая на вопросы мантейнеров
3) Практически нет корпоративных почтовых адресов, то есть получается компании не заинтересованы в драйверах на RUST
Без относительности хорошо RUST для ядра или плохо - может проблема в комьюнити rust-for-linux ?
Спасибо за ответ, тем не менее:
Ни разу не замечал, есть более строгие подсистемы например clk, pinctrl и dt, а есть, так скажем, более мягкие, где закрывают глаза на недочеты, но при этом в более мягких нельзя рассчитывать, что "и так сойдет".
Отчасти согласен, но вся эта прелесть конечно не снимает необходимость тестирования во время которого гарантировать отсутствия таких ошибок может например KSAN.
А вот это между прочим очень болезненный вопрос, который может исключить дальнейшее использование некоторых процессоров и SoC как например это происходит сейчас https://habr.com/ru/news/537100/.
Вопросы к знатокам:
1)
Почему кстати говоря ?
2)
А есть что-то такое, что не обнаруживает KASAN, KMSAN и прочие инструменты ядра, но обнаруживает RUST ?
3) Какой итоговый размер получается ядра - с растом и без ?
А ссылочку можно на мэйл листы ?
А вот тут вынужден заметить (внимательно перечитав сопроводительное письмо), что о всех проблемах патча перечисленных Линусом, авторы патча "скромно умолчали", зато выкатили целую рекламную телегу, что "Rust это всегда хорошо !".
Ну справедливости ради когда посылают патчи с плашкой [RFC] никогда и не претендуют на принятие с первого раза.
Так что это даже не "первый раз", а просто "гляньте чё я тут понаделал".
Вы это к чему вообще ?
Претензия заявлена вполне конкретная:
Не ронять все ядро при ошибках выделения памяти, и @KanuTaHимел ввиду именно данный пункт.
Причём тут "молодое" ядро и то как быстро принимаются патчи - к чему эта демагогия ?
В таком случае в первую очередь пожалуйста примите мои извинения за поспешный вывод:
Что касается вашего ответа:
На самом деле на практике получается, что одно и то же время, поскольку все равно компоненты каждый раз загружать заново. Во-вторых можно распаковывать FIT в память и менять, допустим, только Device Tree т.е. записывать его поверх распакованного, хотя с ядром или rootfs это уже будет нецелесообразно.
Сборка FIT из готовых компонентов это ничтожная часть времени от затраченной на сборку всех частей.
UPD:
Получается, что образы несжатые:
Image Type: ARM Linux Kernel Image (uncompressed)Image Type: ARM Linux RAMDisk Image (uncompressed)И кстати говоря
Loading Environment from FAT... *** Error - No Valid Environment Area foundU-Boot поддерживает чтение ENV в том числе из памяти с указанием адреса, т.е. вы можете загружать заранее сформированные ENV под различные ситуации - возможно это вам пригодится.
Поскольку видимо не в привычках автора, отвечать на вопросы, позволю себе некоторые ремарки:
Обычно эволючионный процесс разработки идет в обратную сторону, нежели описал автор - мы начинаем с загрузки файлов по JTAG и постепенно отказываемся от неё по следующим причинам:
загрузка может занимать колоссальное время от "Поковырялся в носу, попил кофе и забыл что делал" до "Два раза загрузил - рабочий день закончился";
по причинам выше мы не можем использовать нормальный rootfs, максимум маленький buildroot или даже просто busybox;
в любом случае нужна сеть, скопировать dmesg, log, perf data и прочее, это просто удобно;
Сжатые kernel и rootfs уже могут нам давать ускорение в несколько раз, замерить можно следующим образом:
инициализировать UART через OpenOCD (просто пишем всё, что необходимо, в соответсвующие регистры);
вывести привественную строку и начать загрузку компонентов;
померять время, например, с помощью grabserial;
Использование же FIT Image (https://docs.u-boot.org/en/latest/usage/fit/index.html) даёт нам некоторую независимость от жестко прописанных адресов в случае загрузки "по частям",
тогда нам, в большинстве случаев, потребуются два жестких адреса - U-Boot SPL и адрес загруженного в память FIT Image.
Но, конечно, всё это не сравнится по скорости и удобству с загрузкой по сети и использовании корневой файловой системы поверх NFS, поэтому я рекомендую направить усилия именно в эту сторону, вплоть до использования SPI Ethernet модуля, если по каким то причинам нет возможности использовать полноценный контроллер.
И конечно всегда интересно посмотреть на замеры времени загрузки.