Установка экзотического модуля ядра

перекомпилировать само ядро

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

https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst

если ты угадал с версией ядра, то будет достаточно сделать insmod. чтобы делать modprobe, надо положить в специальное место типа /lib/modules/6.1.0-23-amd64/kernel/ и выполнить depmod -a

Мне нужно поставить драйвер, о существовании которого ядро линукса может не знать

Что это значит? Что модуль скомпилирован не через make modules при сборке ядра, а где-то извне? Это неважно.

Самое главное это чтобы модуль был собран против правильной версии ядра, а не наоборот.

Так ядро итак ничего не знает о загружаемых модулях на момент их загрузки. Тут главное чтоб модуль знал всё необходимое о ядре. А если конкретнее - об апи ядра. Именно поэтому для сборки модулей ставится пакет linux-headers. Основная сложность в том, что ядерщики ломают внутреннее апи ядра от версии к версии, поэтому, модуль собранный под одну версию ядра, запросто может не заработать с другой версией.

Может быть и так и так. Зависит от конфигурации ядра и чего нужно модулю в качестве зависимостей

Бинарный ko собирается под определенную версию ядра и работает с ней.

Надо

1. Убедиться что у тебя такая версия ядра, под которую собран модуль.

2. Положить в нужное место, запустить через modprobe.

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

Если такая поставка, то обычно идет какой-то инсталлятор, скрипт который собирает модуль и кладет куда надо.

Про nonsense я, разумеется, слышал. А есть где-нибудь таблицы, в каких версиях вносятся несовместимые изменения и какие именно? И вообще, насколько часто эта ломка происходит?

Ядро пересобирать надо только в том случае, если у этого модуля есть зависимости, которые отключены в твоем штатном ядре. Если это ядро из обычного бинарного дистрибутива - это очень маловероятно, там все врублено по максимуму.

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

А есть где-нибудь таблицы

ахаха ))

diff linux-headers :)
при каждой компиляции ядра местоположения точек функций новое, я так понимаю.

погугли module_layout

ko блоб дикость, если производитель совсем мудак, то лучше такое отреверсить и написать по своему.

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

Ядра кстати часто собираются с валидацией модулей, он может такое отказаться грузить. Может быть есть флаг разрешающий, но я на практике ядро пересобирал без этой валидации.

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

Enterprise ядра вроде RHEL дают некоторые гарантии. Там можно пытаться писать модули, которые будут работать с минорными обновлениями. Хотя это так, вилами по воде. Но в большинстве дистрибутивов гарантий 0 и надо пересобирать после каждого обновления.

ko блоб дикость, если производитель совсем мудак, то лучше такое отреверсить и написать по своему

в реальном мире вполне себе распространено, производители различных SoC так предоставляют значительную часть, но в данном случае, как правило, проблемы нет так как поставщик linux и ko один

К сожалению, столкнулся с таким относительно недавно от производителя одного микроконтроллера с поддержкой wifi. Собственно, их драйвер мало того закрыт, так ещё и не юзает стандартные интерфейсы в линуксе для управления этим вайфаем.

Но в линукс эмбеддеде работаю давно и до сих пор именно блобов модулей не было.

Чего ахаха, у ffmpeg, например, есть вот такая прррелесссть (спасибо a1ba). Неужели ядро хуже?

у ffmpeg

ну, ты сравнил, канеш, хрен с пальцем… ядро необъятно, в нем есть masturbating monkeys, раст, и даже небо и даже аллах! А исходники ффмпег можно легко выучить наизусть за вечер.

Ладно, шутки в сторону. Ядро не хуже, оно просто обширнее.

А есть где-нибудь таблицы, в каких версиях вносятся несовместимые изменения и какие именно?

Неужели ядро хуже?

Некоторое представление о данной проблеме можно получить ознакомившись, например, с содержимым kcompat* файлов, поставляемых с интеловским out-of-tree igb драйвером

Надо перекомпилить ядро потому что размер структур, всякие мутексы-workи и прочие структуры могут отличаться.

По уму если драйвер не адово сложный имеет смысл его декомпилятором разобрать и собрать заново

если ты угадал с версией ядра, то будет достаточно сделать insmod.

Не совсем так, ещё зависимости в ядре должны быть включены. Допустим модуль использует некоторый алгоритм шифрования, включающийся в ядре опцией. Если нет какой-либо функциональной зависимости - не заработает.

Это ещё про совместимость вызовов в принципе.

Надо перекомпилить ядро

Самое скверное, что в ряде задач ещё и ядро в виде блоба, и поменять его не выйдет по организационным причинам.

В этом случае есть шанс, что жабо-ядро удастся скрестить с гадюко-модулем? Да, то, что версии должны быть максимально близки, это я понимаю.

(Насколько, кстати, близки, если модуль собирался под 6.0, а в наличии ядро 6.1, например – шансы есть?)

А исходники ффмпег можно легко выучить наизусть за вечер.

Я видел те исходники. Это мягко говоря не на вечер и даже не на месяц. Куча своих определений, проверок… И в принципе, это правильно. Поддерживать всё, что шевелится, не такая простая задача.

Я видел те исходники.

Я видел исходники ядра. Хуже - бывает, я в них пишу (к счастью, приватно)

И ты посмотри их, ну, для общего, так сказать, развития 🤭

Синелерра об эту прелесть каждый раз больно стукается.