# depinfo -k 5.10.19-un-def-alt1 rmi_core module /lib/modules/5.10.19-un-def-alt1/kernel/drivers/input/rmi4/rmi_core.ko module /lib/modules/5.10.19-un-def-alt1/kernel/drivers/media/common/videobuf2/videobuf2-v4l2.ko module /lib/modules/5.10.19-un-def-alt1/kernel/drivers/media/common/videobuf2/videobuf2-common.ko module /lib/modules/5.10.19-un-def-alt1/kernel/drivers/media/mc/mc.ko module /lib/modules/5.10.19-un-def-alt1/kernel/drivers/media/v4l2-core/videodev.ko module /lib/modules/5.10.19-un-def-alt1/kernel/drivers/media/common/videobuf2/videobuf2-vmalloc.ko module /lib/modules/5.10.19-un-def-alt1/kernel/drivers/media/common/videobuf2/videobuf2-memops.ko
Разбиение модулей на подпакеты давно [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, зависимости между модулями ядра теперь контролируются автоматически.
