compilation module for kernel

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

>> Компилирую модуль для ядра в дебиане ленни. В нём самом модуль подгружается в ядро. В дистре puppy 4.00 загрузка модуля в ядро выдаёт ошибку: Linux version 2.6.21.7 (root@puppypc) (gcc version 4.2.2) #1 Sun Feb 24 10:22:08 GMT-8 2008 ... test: no version for "struct_module" found: kernel tainted. test: version magic '2.6.18 SMP mod_unload 686 REGPARM gcc-4.1' should be '2.6.21.7 mod_unload 486 '

>> Что нужно сделать, чтобы модуль корректно подгружался?

Модуль должен быть собран под ту же версию ядра, под которой он будет загружаться и работать. И желательно (а может и обязательно - я не уверен) той же версией компилятора. Так что либо собирай модуль на puppy, либо поставь в debian исходники ядра (и компилятор?), которое используется в puppy.

> И желательно (а может и обязательно - я не уверен) той же версией компилятора.

Это если платформа другая, то кросскомпиляция нужна, ну или на целевой платформе и компилить. Зачем в других случаям может понадобиться та же версия компилятора - на представляю.

У меня в дебиане 2.6.18 было ядро скомпилёное под gcc-4.1 - модуль подгружался нормально. Обновил ядро до 2.6.18-6-686, модуль перестал подгружаться - пишет сигнатура не та и версия компилятора не совпадает, типа модуль скомпилён gcc-4.1, а ему надо gcc-4.2

Залез в главный Makefile ядра, поменял gcc-4.1 на gcc-4.1 - модуль стал подгружаться без ошибок. Поэтому и задаю здесь вопрос, может ещё кроме верии компилятора надо будет.

Буду пробовать.

> Зачем в других случаям может понадобиться та же версия компилятора - на представляю.

Может изменить формат объектников или какие-нить баги в компилере итп. Не только другая версия gcc может вызвать проблемы, но и binutils.

> Может изменить формат объектников или какие-нить баги в компилере итп. Не только другая версия gcc может вызвать проблемы, но и binutils.

Я только один раз помню, когда в GCC ABI менялся... но так согласен.. может понадобиться та же версия компилятора..

т. к требуемая строка
'2.6.21.7 mod_unload 486 '
меньше исходной
'2.6.18 SMP mod_unload 686 REGPARM gcc-4.1'
то можно пропатчить соответствующую строку в .ko файле
это грязный хак и правильную работу после этого я не гарантирую

Можноли скомпилить модуль таким образом, чтобы он подходил ко всем ядрам версий 2.6.18 или ко всем ядрам версии 2.6.21.7 ? Т.е. по аналогии как в микроядерных системах?

1. интерфейс должен совпадать
(чтобы не получилось так, что в модуле идет вызов функции, которой в другой версии ядра нет)
2. убрать из .ko vermagic

1. это ясно 2. что значит убрать? затереть пробелами?

> Я только один раз помню, когда в GCC ABI менялся...

Ты про смену между 2.x до 3.0? :). Были ещё исправления, не помню в каких версиях. Плюс всякие фишки типа pie, ssp могут создавать несовместимыей объектники.

Даже доки к ядру это рекомендуют (oops-tracing.txt): Oh, it helps if the report happens on a kernel that is compiled with the same compiler and similar setups.

Короче, если есть возможность, лучше не шутить с компилятором :)

> 2. что значит убрать?

затереть нулями