Создание переносимого в пределах 2.6.* модуля ядра

Если под скомпилированным объектником подразумевается некий готовый module.ko, то нет. Посмотри как собираются модули ядра закрытых драйверов для видеокарт (nvidia, ati).

Оставь надежду. Слишком уж большой интервал по версиям ядра ты взял. За это время уйму раз API ломали. Хотя, возможно, и не всё ещё сломали.

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

> Возможно ли вообще такое?

Если использовать RHEL, в котором блюдут kernel ABI, то да, в пределах одной мажорной версии возможно.

> Если использовать RHEL, в котором блюдут kernel ABI, то да, в пределах одной мажорной версии возможно.

Щас! Только с insmod -f, поскольку version magic в модулях еще никто не отменял. По делу - можно сделать по принципу nvidia, как уже отмечалось. То есть вся логика строится на своих структурах и функциях, а для "выхода в ядро" пишутся короткие врапперы.

> Щас! Только с insmod -f, поскольку version magic в модулях еще никто не отменял.

И? Модуль, написанный для 5.0, будет работать и в 5.3.

вот этот механизм был придуман специально для таких случаев: http://en.wikipedia.org/wiki/DKMS

это, конечно, не module.ko, но в дистрибах успешно решает данную проблему

Не шуточные дебаты:) В общем, как я понял, у меня есть три возможных выхода: 1) Остановиться на "хорошем" дистрибутиве, например, RH, с которым все должно быть ОК из-за их политики разработки. Не хорошо то, что я опять же сужаю круг платформ, на которых будет успешно работать мой моудль; 2) Написать некоторый ядрозависимый уровень абстракции, на интерфейсах которого написать уже свой модуль. Проблема, которую я вижу здесь - необходимость компилирования модуля абстракции на целевой машине (компилятора может не оказаться), либо таскания с собой кучи уже откомпиленных модулей абстракци. 3) Использование технологии DKMS, которая позволит адаптировать мой модуль ядра под имеющееся ядро. Проблема, которую я вижу здесь - не у всех пользователей установлен соответствующий пакет, например, в убунте он был включен в дефолтную конфигурацию с версии 8.04, которая работает на Linux kernel 2.6.27. Почитал документацию по этой технологии, но не совсем понял, что они подразумевают под автоматической адаптацией под новое ядро? я должен дать исходники и система их сама откомпилит? Если так, то чем это отличается от обычного Makefile?

> И? Модуль, написанный для 5.0, будет работать и в 5.3.

а для 4.x в 5.3 будет работать? ага, разбежались..

// wbr

а настолько ли необходимо делать вообще блоб в ядро?
если делаете закрытый проект, гораздо лучше (для всех)
сделать открытый модуль ядра, с исходниками и прочим, вместить в него тот самый минимум который требуется in kernel mode

а все свои закрытые алгоритмы реализуйте уже в user-space,

поверьте blob'ов итак хватает и проблем от них тоже хватает

> а настолько ли необходимо делать вообще блоб в ядро? если делаете закрытый проект, гораздо лучше (для всех) сделать открытый модуль ядра, с исходниками и прочим, вместить в него тот самый минимум который требуется in kernel mode

"лучше для всех" - это весьма спорный вопрос. а если "всем" или хотя бы 2% от всех мой модуль нафик не нужен? сугубо специфичная вещь под конкретный проект для сравнительно узкого круга лиц. прикажите и это пихать в общее ядро? зачем? кто этим будет заниматься? кто его будет поддерживать в ядре [это совсем не то же самое, что поддерживать у себя]? кто вообще будет отвечать за взаимодействие с kernel team? и так далее и тому подобное. вопросов хватает. тем более, что модуль скорее всего новый -> в самом оптимистичном варианте его может быть получится запихнуть в ветку через полгодика. а что делать с текущими юзерами? а не приведи господи некоторые из них сидят на RHEL4x/5x? и это только RHEL. а есть ещё и другие дистрибутивы. в общем, на практике - Геморой в квадрате. нет, в кубе. и магические "открытые исходники" - это ещё отнюдь не панацея. даже если их и можно в принципе сделать открытыми.

// wbr

про то чтобы сделать commit этого модуля в upstream-ное ядро я ничего не писала,
всего лишь имею ввиду то что исходники модуля будут доступны вместе с дистрибутивом программ для которых этот модуль требуется

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

> а для 4.x в 5.3 будет работать? ага, разбежались..

И? У остальных и такого нет.

> всего лишь имею ввиду то что исходники модуля будут доступны вместе с дистрибутивом программ для которых этот модуль требуется

к сожалению, само по себе доступность исходников не решит проблем переносимости модуля в пределах 2.6.x и он будет точно так же увешан ifdef-else-endif как новогодняя ёлка игрушками :(

// wbr

> И? У остальных и такого нет.

кого волнуют абстрактные "остальные"? круг задач вполне чётко очерчен и выходить за него смысла нет никакого. с этим бы разгребстись..

// wbr

Получается, в пространстве 2.6.* ни в исходных кодах, ни в скомпиленном виде ничего универсального сделать невозможно? Насколько вообще меняется интерфейс ядра? мне всего лишь пока надо реализовать простейший контроль доступа к файлам. Делов-то? Фильтрануть пару вызовов и на этом мое знакомство с ядром должно пока завершиться. Но вот проблема - у пользователя может вообще не стоять gcc и ничего он не скомпилирует. Часть специфических вещей можно оформить в виде конфига, который поправить из юзермода до загрузки модуля, который потом прочитает эту конфигурацию и будет адаптирован к данной системе. С юзермодом без компиляции, как мне кажется, проблем не должно бать, а вот с модулем - беда просто.