Bug 39763

Разбиение модулей на подпакеты давно [1] уже не соответствует зависимостям между модулями.

Например

$ depinfo drm_kms_helper
module /lib/modules/5.10.19-un-def-alt1/kernel/drivers/gpu/drm/drm_kms_helper.ko
module /lib/modules/5.10.19-un-def-alt1/kernel/drivers/gpu/drm/drm.ko
module /lib/modules/5.10.19-un-def-alt1/kernel/drivers/media/cec/core/cec.ko
module /lib/modules/5.10.19-un-def-alt1/kernel/drivers/media/rc/rc-core.ko

Разработчики ядра выделили реализацию Consumer Electronics Control [2] в отдельный модуль,
и используют его везде, где потребуется (например, в драйверах hdmi). И никого не волнует,
что мы когда-то решили, что между drivers/gpu и drivers/media нет и не может быть зависимостей.

Поскольку ядро - единое целое (см. stable api nonsense), то нет никакой гарантии, что такие
"неожиданные" зависимости не появятся вновь. Скорее наоборот - любое разбиение модулей ядра
на подпакеты гарантировано приведет к тому, что либо

1) все подпакеты (с модулями) будут зависеть друг от друга (уже произошло для modules-drm и modules-v4l)
2) часть модулей подпакета будет неработоспособна из-за отсутствующих зависимостей,
   (которые "счастливые" пользователи должны будут найти вручную). До недавнего времени
   такая ситуация была с kernel-modules-drm-std-def: модуль dw_hdmi.ko не грузился,
   если не установлен пакет kernel-modules-v4l-def


Поэтому считаю, что

1) Все (in-tree) модули нужно паковать в пакет kernel-image
2) Те, кто боится, что на его любимом сервере загрузится drm.ko, могут внести его в blacklist.
   В "серверные" образы такой blacklist можно включить по умолчанию.  
3) Для экономии дискового пространства/траффика использовать сжатие модулей (CONFIG_MODULE_COMPRESS=y, CONFIG_MODULE_COMPRESS_XZ=y),
   kmod уже собран с поддержкой сжатых модулей


[1] Как минимум со времен ядра 4.9, но на x86 это было не так заметно
[2] https://en.wikipedia.org/wiki/Consumer_Electronics_Control

(Ответ для Alexey Sheplyakov на комментарий #1)
> $ depinfo drm_kms_helper
Я уже напоролся с amdgpu.

Есть ещё одно решение -- написать генератор rpm зависимостей между модулями ядра, задача не то, чтоб выглядит сложной, но никто пока не взялся. И, соответственно, менять раскладку модулей в соответствии с результатами работы этого генератора...

(In reply to Anton V. Boyarshinov from comment #3)
> Есть ещё одно решение -- написать генератор rpm зависимостей между модулями
> ядра, задача не то, чтоб выглядит сложной, но никто пока не взялся. И,
> соответственно, менять раскладку модулей в соответствии с результатами
> работы этого генератора...


1) Как быть с обновлениями? "Жил" себе модуль в kernel-image, и тут мы решили его
   перенести в modules-v4l. Пользователь, у которого не был установлен modules-v4l,
   после update-kernel получит тыкву.

2) Что делать с циклическими зависимостями (вроде modules-v4l/modules-drm)?


"Все нужное - не сложно, все сложное - не нужно"

(Ответ для Alexey Sheplyakov на комментарий #1)
> Разбиение модулей на подпакеты давно [1] уже не соответствует зависимостям
> между модулями.
> 
> $ depinfo drm_kms_helper
> module
> /lib/modules/5.10.19-un-def-alt1/kernel/drivers/gpu/drm/drm_kms_helper.ko
> module /lib/modules/5.10.19-un-def-alt1/kernel/drivers/gpu/drm/drm.ko
> module /lib/modules/5.10.19-un-def-alt1/kernel/drivers/media/cec/core/cec.ko
> module /lib/modules/5.10.19-un-def-alt1/kernel/drivers/media/rc/rc-core.ko

Это учтено уже некоторое время как.

> Разработчики ядра выделили реализацию Consumer Electronics Control [2] в
> отдельный модуль,
> и используют его везде, где потребуется (например, в драйверах hdmi). И
> никого не волнует,
> что мы когда-то решили, что между drivers/gpu и drivers/media нет и не может
> быть зависимостей.
> 
> Поскольку ядро - единое целое (см. stable api nonsense), то нет никакой
> гарантии, что такие
> "неожиданные" зависимости не появятся вновь. Скорее наоборот - любое
> разбиение модулей ядра
> на подпакеты гарантировано приведет к тому, что либо
> 
> 1) все подпакеты (с модулями) будут зависеть друг от друга (уже произошло
> для modules-drm и modules-v4l)
Вообще говоря, добавление части модулей из v4l в drm, как эта проблема решалась раньше, не создаёт такой зависимости.

> 2) часть модулей подпакета будет неработоспособна из-за отсутствующих
> зависимостей,
По хорошему, нужна автгенерация и автопоиск зависимостей..

> 3) Для экономии дискового пространства/траффика использовать сжатие модулей
> (CONFIG_MODULE_COMPRESS=y, CONFIG_MODULE_COMPRESS_XZ=y),

К сожалению, сжатые модули оказались несовместимы с EMA/EVM

разбивать kernel-image на модули просто несусветная глупость. там не такой большой объем что бы на этом экономить

https://bugzilla.altlinux.org/show_bug.cgi?id=25852
https://bugzilla.altlinux.org/show_bug.cgi?id=28926
мы эти кактусы смакуем уже очень давно.
идею перестать выделять in-tree модули в подпакеты нахожу здравой.

(Ответ для Sergey Bolshakov на комментарий #7)
> идею перестать выделять in-tree модули в подпакеты нахожу здравой.
+1

(Ответ для Anton V. Boyarshinov на комментарий #3)
> Есть ещё одно решение -- написать генератор rpm зависимостей между модулями
> ядра, задача не то, чтоб выглядит сложной, но никто пока не взялся. И,
> соответственно, менять раскладку модулей в соответствии с результатами
> работы этого генератора...
Т.е. генератор будет делать новый набор подпакетов с каждой минорной версией ядра.
В результате после нескольких обновлений минора при помощи update-kernel машина остаётся вообще без каких-либо kernel-modules.

Как вариант -- оставить 2 пакета: kernel-image и kernel-modules.

(Ответ для Sergey V Turchin на комментарий #10)
> Как вариант -- оставить 2 пакета: kernel-image и kernel-modules.
А их уже автогенератором делИть.
Например, давая ему список необходимых в kernel-image модулей, чтоб остальное по возможности отбрасывалось в kernel-modules.

(Ответ для Alexey Sheplyakov на комментарий #4)
> (In reply to Anton V. Boyarshinov from comment #3)
> > Есть ещё одно решение -- написать генератор rpm зависимостей между модулями
> > ядра, задача не то, чтоб выглядит сложной, но никто пока не взялся. И,
> > соответственно, менять раскладку модулей в соответствии с результатами
> > работы этого генератора...
> 
> 
> 1) Как быть с обновлениями? "Жил" себе модуль в kernel-image, и тут мы
> решили его
>    перенести в modules-v4l. Пользователь, у которого не был установлен

В эту сторону переносов пока не было. Кроме того, ничто не мешает файлу быть одновременно в нескольких подпакетах.

(Ответ для Sergey V Turchin на комментарий #9)
> (Ответ для Anton V. Boyarshinov на комментарий #3)
> > Есть ещё одно решение -- написать генератор rpm зависимостей между модулями
> > ядра, задача не то, чтоб выглядит сложной, но никто пока не взялся. И,
> > соответственно, менять раскладку модулей в соответствии с результатами
> > работы этого генератора...
> Т.е. генератор будет делать новый набор подпакетов с каждой минорной версией
> ядра.
> В результате после нескольких обновлений минора при помощи update-kernel
> машина остаётся вообще без каких-либо kernel-modules.

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

внимание вопрос! какую задачу вы решаете выделяя какие то модули из kernel-image в kernel-modeles?

(Ответ для Anton V. Boyarshinov на комментарий #13)
> Генератор зависимостей, а не подпакетов.
Все будут тупо друг от друга зависеть.

(Ответ для Valery Inozemtsev на комментарий #14)
> какую задачу вы решаете
Разве не SUBJ?

(Ответ для Sergey V Turchin на комментарий #16)
> (Ответ для Valery Inozemtsev на комментарий #14)
> > какую задачу вы решаете
> Разве не SUBJ?

ни разу ни SUBJ. поставлю вопрос по другому. ЗАЧЕМ разбивать kernel-image на подпакеты?

(Ответ для Valery Inozemtsev на комментарий #17)
> ЗАЧЕМ разбивать kernel-image на подпакеты?
Это тема другой баги, хоть её тут уже слегка и обсуждали.

вот это и надо обсуждать, а не изобретать <strike>велосипедные велосипеды</strike> генератор зависимостей

(Ответ для Valery Inozemtsev на комментарий #17)
> (Ответ для Sergey V Turchin на комментарий #16)
> > (Ответ для Valery Inozemtsev на комментарий #14)
> > > какую задачу вы решаете
> > Разве не SUBJ?
> 
> ни разу ни SUBJ. поставлю вопрос по другому. ЗАЧЕМ разбивать kernel-image на
> подпакеты?

Хотя бы для того, чтоб не ставить сомнительный код из дерева staging без крайней необходимости.

Есть вовсе ненулевое число людей, которые не хотят видеть на своих серверах модули drm ни в каком виде (blacklst это отлично, но его надо регулярно обновлять).

Способ переключения между nvidia и noveau через установку пакетов лично мне представляется удобнее других. А вот radeon больше не на что переключать и подпакет -radeon стоит включить в drm.

Подпакет -drm-ancient был выделен, по настоятельной просьбе кого-то в офисе, кажется shrek@

Подпакет v4l я во вчерашней сборке целиком включил в подпакет drm, так что данную багу можно считать исправленной.

> Подпакет v4l я во вчерашней сборке целиком включил в подпакет drm,
rmi_core тоже?

> > ни разу ни SUBJ. поставлю вопрос по другому. ЗАЧЕМ разбивать kernel-image на
> > подпакеты?
> 
> Хотя бы для того, чтоб не ставить сомнительный код из дерева staging без
> крайней необходимости.

1) blacklist по умолчанию всего staging
2) kernel-modules-staging, и проблемы с зависимостями нет: обычные модули от staging не зависят
 

> Есть вовсе ненулевое число людей, которые не хотят видеть на своих серверах
> модули drm ни в каком виде (blacklst это отлично, но его надо регулярно
> обновлять).

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

А те, кто знают, что такое drm, и "не хотят его видеть", наверное знают про rm,
rpm --excludepath, blacklist, и прочее.


> Способ переключения между nvidia и noveau через установку пакетов лично мне
> представляется удобнее других.

Это все равно, что переключаться между vim и emacs через установку пакетов. Неудобно.

$ depinfo -k 5.10.22-un-def-alt1 rmi_core
module /lib/modules/5.10.22-un-def-alt1/kernel/drivers/input/rmi4/rmi_core.ko
module /lib/modules/5.10.22-un-def-alt1/kernel/drivers/media/common/videobuf2/videobuf2-v4l2.ko
module /lib/modules/5.10.22-un-def-alt1/kernel/drivers/media/common/videobuf2/videobuf2-common.ko
module /lib/modules/5.10.22-un-def-alt1/kernel/drivers/media/mc/mc.ko
module /lib/modules/5.10.22-un-def-alt1/kernel/drivers/media/v4l2-core/videodev.ko
module /lib/modules/5.10.22-un-def-alt1/kernel/drivers/media/common/videobuf2/videobuf2-vmalloc.ko
module /lib/modules/5.10.22-un-def-alt1/kernel/drivers/media/common/videobuf2/videobuf2-memops.ko

$ rpm -q --whatprovides /lib/modules/5.10.22-un-def-alt1/kernel/drivers/input/rmi4/rmi_core.ko
kernel-image-un-def-5.10.22-alt1.aarch64
$ rpm -q --whatprovides /lib/modules/5.10.22-un-def-alt1/kernel/drivers/media/common/videobuf2/videobuf2-v4l2.ko
kernel-modules-drm-un-def-5.10.22-alt1.aarch64

Для работы модуля из kernel-image-un-def по-прежнему требуется модуль из пакета kernel-modules-drm-un-def.

(In reply to Anton V. Boyarshinov from comment #12)

> > 1) Как быть с обновлениями? "Жил" себе модуль в kernel-image, и тут мы
> > решили его
> >    перенести в modules-v4l. Пользователь, у которого не был установлен
> 
> В эту сторону переносов пока не было. 

"Теперь будут". Вот прямо сейчас модуль rmi_core может внезапно переехать в какой-нибудь подпакет.

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

А зачем в таком случае было делить на подпакеты?

(In reply to Sergey V Turchin from comment #11)
> (Ответ для Sergey V Turchin на комментарий #10)
> > Как вариант -- оставить 2 пакета: kernel-image и kernel-modules.
> А их уже автогенератором делИть.
> Например, давая ему список необходимых в kernel-image модулей, чтоб
> остальное по возможности отбрасывалось в kernel-modules.

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

(Ответ для Alexey Sheplyakov на комментарий #23)

> Для работы модуля из kernel-image-un-def по-прежнему требуется модуль из
> пакета kernel-modules-drm-un-def.

Упс, я всё это время неправильно понимал в чём проблема, привычно интерпретировав её как новую зависимость drm от v4l, хотя всё было совершенно не так, спасибо.

(Ответ для Alexey Sheplyakov на комментарий #22)
> > > ни разу ни SUBJ. поставлю вопрос по другому. ЗАЧЕМ разбивать kernel-image на
> > > подпакеты?
> > 
> > Хотя бы для того, чтоб не ставить сомнительный код из дерева staging без
> > крайней необходимости.
> 
> 1) blacklist по умолчанию всего staging
Ммм.. там ведь, кажется, никакие маски не поддерживаются, так что список будет немаленький (понятно, что сгенерировать можно список любого размера)

> 2) kernel-modules-staging, и проблемы с зависимостями нет: обычные модули от
> staging не зависят
Случаи такие бывали, но как правило это действительно так.

> > Есть вовсе ненулевое число людей, которые не хотят видеть на своих серверах
> > модули drm ни в каком виде (blacklst это отлично, но его надо регулярно
> > обновлять).
> 
> Не понятно, почему дистрибутив должен быть по умолчанию заточен под желания
> именно этой группы людей.

"Дистрибутив по умолчанию" и "разбиение на пакеты" это немного разные истории. На дистрибутив по умолчанию больше влияет не разбиение на пакеты как таковое, а то, какие пакеты мы в него кладём. И если относительно мелкая нарезка на пакеты позволяет такой выбор делать, то её отсутствие -- не позволяет.

И не учитывать при нарезке пакетов мнение ldv@ и glebfm@ для меня было бы довольно странно.

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

> А те, кто знают, что такое drm, и "не хотят его видеть", наверное знают про
> rm,
> rpm --excludepath, blacklist, и прочее.
rm для файлов из пакетов и rpm --excludepath у нас не является рекомендуемым способом использования системы.

А относительно мелкая нарезка пакетов -- является. И пока вы не убедите ldv@ в том, что ядро больше не надо нарезать на подпакеты (а он потом -- меня), меня убеждать бесполезно.

> 
> 
> > Способ переключения между nvidia и noveau через установку пакетов лично мне
> > представляется удобнее других.
> 
> Это все равно, что переключаться между vim и emacs через установку пакетов.

В рамках формирования дистрибутива именно этот метод и используется. В том числе , для переключения между vim и emacs, который, последнее время, обычно просто не попадает в дистрибутивы (и таки да, кому надо -- поставит).

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

при этом можно будет считать ошибкой зависимость ядра на пакет с модулями.

(Ответ для Anton Farygin на комментарий #28)
> вообще весь ваш диалог похоже, сводится к тому, что нужно кому-то сесть и
> написать генератор межпакетных зависимостей, основанный на зависимостях
> между модулями.

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

> при этом можно будет считать ошибкой зависимость ядра на пакет с модулями.
Да, пожалуй. Что-нибудь вроде "kernel-image не должен иметь файловых завимостей в /lib/modules"

(In reply to Anton Farygin from comment #28)
> вообще весь ваш диалог похоже, сводится к тому, что нужно кому-то сесть и
> написать генератор межпакетных зависимостей, основанный на зависимостях
> между модулями.

Нет. Во-первых, кому-то надо сесть и сформулировать, зачем нужно in-tree модули разбивать на подпакеты. Для решения какой *технической* проблемы это нужно. Пока что я видел - "чтобы уважаемые люди (TM) не расстроились". Но это не техническая проблема.

А во-вторых, все упорно забывают про обновления. Кроме "генератора зависимостей" надо еще "немного" доработать update-kernel, чтобы, например, ничего не ломалось  при обновлении с 5.4 на 5.10. 

> при этом можно будет считать ошибкой зависимость ядра на пакет с модулями.

И что делать в случае такой ошибки? Вот модуль rmi_core из kernel-image завист от modules-drm. Дальше что?

(Ответ для Alexey Sheplyakov на комментарий #30)
> надо еще "немного" доработать update-kernel, чтобы, например,
> ничего не ломалось  при обновлении с 5.4 на 5.10.

Как доработать?

ps. Про update-kernel у меня ещё мысль, запишу её хотя бы здесь - если при апгрейде нет нужного модуля (скажем, он не собрался и его удалили), тем более загруженного, то выводить предупреждение пользователю.

(In reply to Anton V. Boyarshinov from comment #27)

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

А после update-kernel получат тыкву

> И не учитывать при нарезке пакетов мнение ldv@ и glebfm@ для меня было бы
> довольно странно.

Вот заставить бы этих прекрасных людей ездить к клиентам и починить последствия update-kernel.
Или собирать образы для каких-нибудь чудесных arm/mips плат.
И понаблюдать за их мнением. Мечты, мечты...

(In reply to Vitaly Chikunov from comment #31)
> (Ответ для Alexey Sheplyakov на комментарий #30)
> > надо еще "немного" доработать update-kernel, чтобы, например,
> > ничего не ломалось  при обновлении с 5.4 на 5.10.
> 
> Как доработать?
> 
> ps. Про update-kernel у меня ещё мысль, запишу её хотя бы здесь - если при
> апгрейде нет нужного модуля (скажем, он не собрался и его удалили), тем
> более загруженного, то выводить предупреждение пользователю.

Набор "нужных" модулей зависит от версии ядра.
Например в 5.4.x (на x86) drm_kms_helper.ko не зависел от cec.ko, а в 5.10 ВНЕЗАПНО уже зависит.

А еще бывает, что раньше модуль поддерживал железяку с pci id NNNN, а потом поддержку этой железяки "занялся" другой драйвер (например, драйвер "переехал" из staging и по пути поменял имя)

(In reply to Alexey Sheplyakov from comment #33)
> (In reply to Vitaly Chikunov from comment #31)
> > (Ответ для Alexey Sheplyakov на комментарий #30)
> > > надо еще "немного" доработать update-kernel, чтобы, например,
> > > ничего не ломалось  при обновлении с 5.4 на 5.10.
> > 
> > Как доработать?
> > 
> > ps. Про update-kernel у меня ещё мысль, запишу её хотя бы здесь - если при
> > апгрейде нет нужного модуля (скажем, он не собрался и его удалили), тем
> > более загруженного, то выводить предупреждение пользователю.
> 
> Набор "нужных" модулей зависит от версии ядра.
> Например в 5.4.x (на x86) drm_kms_helper.ko не зависел от cec.ko, а в 5.10
> ВНЕЗАПНО уже зависит.
> 
> А еще бывает, что раньше модуль поддерживал железяку с pci id NNNN, а потом
> поддержку этой железяки "занялся" другой драйвер (например, драйвер
> "переехал" из staging и по пути поменял имя)

Еще пример: разделение efivars на собственно efivars и efivarfs (в 5.10). Без efivarfs нет /sys/firmware/efi/efivars, и не работает efibootmgr

в 5.10.23 данные (и ещё некоторые) модули перенесены в kernel-image, зависимости между модулями ядра теперь контролируются автоматически.