Надеюсь смог внятно объяснить.
Не смог. Попробую еще раз.
Суть проблемы с нашими 'резанными' ядрами, что за основу берется древний конфиг Pro, который создавался при царе Горохе и многих авторских фич и оптимизаций там просто нет, плюс нет поддержки железа до 2021 года включительно.
Если бы у автора pf было на gitlab указание по годам, что он добавил в ядра, какие изменения, было бы проще. 'Мы' бы брали конфиг Pro как основу и добавляли эти изменения. Но такого нет, у post-factum только кратенький анонс некоторых фич, все остальное скрыто под 'капотом'.
Но ведь тогда вроде возникает прекрасная идея диффнуть авторский конфиг относительно Pro, как сейчас и делает sfs. Но вот здесь и требуется высокая квалификация сборщика - что вернуть обратно, а что нет, при этом не сломав настроенное автором. И этой квалификации нет у sfs, как он сам и признает.
Что я предложил вчерашним постом, попытаюсь дать более развернутый ответ: - Откинуть из авторского конфига полностью все железо с помощью Modprobed-db, запущенного на любом гипотетическом компе... sfs. ) Это будет подобно выжатой мокрой тряпке, авторский .config очень сильно 'похудеет'. Вся вода - это .config_iron_diff (железо). В сухом остатке - .config_optimizations (все фичи, оптимизации и настройки), в него не лезем, т.к. не имеем "понимания".
- Берем пустой .config_pra, копируем в него .config_optimizations, как есть, и только теперь начинаем вдумчиво добавлять параметры из .config_iron_diff. Здесь может помочь на начальном этапе конфиг Pro, т.е. все совпадения с .config_iron_diff берем не задумываясь. А вот дальше уже надо думать..., наверно 'шерстить' наши темы, типа соседней темы с планшетом.
p.s. Для понимания, зачем такие 'извращения' и почему бы не брать полное авторское ядро, прикрутив к нему aufs:
- Чем меньше конфиг, тем быстрее соберется ядро, с меньшими затратами процессорного времени. Есть и другие резоны, типа маленькое ядро удобней при использовании copy2ram, но считаю это менее важным, чем исключить многочасовой обогрев атмосферы. Не думаю, что конфигурация железа sfs заточена на компиляцию разных тяжелых проектов.
Возможно, если бы post-factum добавил поддержку aufs в свои ядра, было бы проще. Учитывая, что он выкладывает бинарные сборки, достаточно было бы собрать модуль aufs c dkms. Но общая тенденция в мире линукс, отказ от него в пользу overlay.