[devel] Новая схема ведения исходников ядра

[Anton V. Boyarshinov]

Добрый день

> Но как, взяв эти ветки, можно рассчитывать, что они лягут на то или
> иное мажорное ядро.
> 
> Хорошо, что хоть эти ветки обновляются с --force,

Эти ветки как правило не обновляются с --force. За последнее время
такой случай был один и был связан с ошибкой при rebase.

> но тогда как найти
> предыдущие варианты, которые "вмержены" в более старые, всем
> интересные, актуальные LTS-ядра?

При возникновении значимых расхождений с новыми мажорными версиями
создаются новые ветки на основе более свежих ядер. Например:

feat-altha-kiosk
feat-altha-kiosk-5.8

В ядре 5.8 LSM сильно переделали и была создана такая новая ветка. Которая неизменной мержится во все ядра с 5.8 включительно (там возникают тривиальные конфликты в Makefile и Kconfig, но они действительно тривиальны)


> И как потом можно рассчитывать, что
> получившиеся исходники будут ровно теми, которые мы собираем? Мы ведь
> и "начерипикать" можем (и делаем это регулярно)?

Исходниками которые мы собираем будут только ровно те исходники,
которые мы собираем. И это в немалой степени касается и файлов не
входящих в апстримные исходники, как то конфигов и spec, в котором в
частности описано как из этих кусков конфигов создаётся итоговый конфиг.

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

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

> Именно эту проблему и предложено решить новой схемой ведения
> исходников ядра. Может быть эту проблему можно решить и иначе. Для
> начала, хотелось бы зафиксировать, что такая проблема есть (иначе
> зачем её решать?)

Я-таки не вполне понимаю, зачем железячникам "все наши патчи", с учётом
того, что существенная часть этих патчей полностью
архитектурно-независима.