LINUX.ORG.RU
Форум — Development  

Как всунуть модуль от другого ядра


0

1

Всем добрый день. Такая проблема, поиском ничего хорошего не нашел. Есть пропатченный (не мной) модуль для ядра 2.6.37. Надо всунуть его в ядро 2.6.32, редхатовское. Он, конечно, билдится, но при modprobe выскакивает «invalid module format», а dmesg говорит, что неправильный «symbol version». Гугл говорит, что это из-за разных версий ядер и я ему верю. Можно ли это как-то решить? Патча для моего ядра не будет, что делать - не знаю.

← [cmake][macos] Несколько бинарников в один bundle
нужна структура данных →

Посмотрите в исходниках, может, можно что-то просто подправить. И да, у меня есть один «самопатченный» модуль (изменить надо было всего лишь пару структур, да чуть в makefile поковыряться), но он почему-то modrpobe'ом не загружался (вызывал подвисание), несмотря на, вроде бы правильную, установку, а вот insmod его подхватывает на ура.

Eddy_Em ☆☆☆☆☆
()

модули то собраны с разным конфигом ядра, там изменет типа проыессора, включено оптимизация размера и т.д. и т.п.

Novell-ch ★★★★★
()
Ответ на: комментарий от Novell-ch

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

Egorkkk
() автор топика
Ответ на: комментарий от Egorkkk

Посмотрите на инклюды (может, некоторые надо убрать или заменить), заполнение «ядерных» структур, а также проверку LINUX_VERSION_CODE.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Egorkkk

> Потому что шапка дает официальную поддержку только на свое ядро.

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

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Egorkkk

Собери на своей машине, только с тем же ядром 2.6.32 и для того же процессора. При загрузке модуля проверяется abi ядра, нужно, чтобы он был таким же.

frey ★★
()

Все, что Вам нуэно сделать:
Нарыть конфиг ядра целевой системы. Обычно ищут в /proc/config.gz или в /usr/src/linux/.config
Достать исходники от этой же версии ядра! Можно, например, скачать rpm пакет из репозитория RedHat. Можно попробовать и ванильные, но лучше из репов.
Далее, сконфигурировать исходники полученным .config и в конце концов скомпилировать свой модуль с этими подготовленными исходниками. Тогда попрет.
Недавно разбирался с такой же проблемой. Здесь дело не только в версии ядра, но и в его окружении. Конкретно, с каким конфигом оно было скомпилировано и в первую очередь, какие были скомпилированы модули. По крайней мере я так понял. По другому не удалось загрузить модуль на чужой машине. Тестировал на gentoo 2.6.37 с целевой системой OpenSuse с типовым ядром 2.6.32.

delete83 ★★
()

99% - не та гцца.

Версия gcc должна совпадать (до 1й цифры после точки включительно) с версией, указанной в /proc/version.

Ну и да, проверьте, что у вас правильный пакет kernel-devel.

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от DELIRIUM

А вот здесь не согласен. У меня точно разные версии gcc были на машинах. На генту последняя из размаскированных 4.5.2, а в OpenSuse я и забыл, когда там gcc обновлялся. По любому еще 4.4.5 или 4.4.6 какой-нибудь стоит. Сейчас на работе, посмотреть не могу, к сожалению. Ядро не использует ни glibc, ни библиотеки gcc. С чего бы ему зависеть от версии компилятора?

delete83 ★★
()
Ответ на: комментарий от DELIRIUM

они могут не сойтись по разным причинам, не только из-за разной гцц

xydo ★★
()
Ответ на: комментарий от DELIRIUM

Эх, заставили меня все таки залезть в в исходники ядра.

Но для начала, пример из моего модуля: 

delete-desktop linux # modinfo /home/work/xtables/kernel-module/xt_UDPSOCKSIFY.ko
filename:       /home/work/xtables/kernel-module/xt_UDPSOCKSIFY.ko
alias:          ipt_UDPSOCKSIFY
description:    udpsocksify xtables target module for UDP
author:         Denis Lebedev <dlebedev@gmail.com>
license:        GPL
srcversion:     C90C50A1A996D5E685EE027
depends:        x_tables
vermagic:       2.6.37-gentoo-delete mod_unload modversions K8

А теперь, собственно, гвоздь программы. Файл vermagic.h из исходников ядра: 

#include <generated/utsrelease.h>
#include <linux/module.h>

/* Simply sanity version stamp for modules. */
#ifdef CONFIG_SMP
#define MODULE_VERMAGIC_SMP "SMP "
#else
#define MODULE_VERMAGIC_SMP ""
#endif
#ifdef CONFIG_PREEMPT
#define MODULE_VERMAGIC_PREEMPT "preempt "
#else
#define MODULE_VERMAGIC_PREEMPT ""
#endif
#ifdef CONFIG_MODULE_UNLOAD
#define MODULE_VERMAGIC_MODULE_UNLOAD "mod_unload "
#else
#define MODULE_VERMAGIC_MODULE_UNLOAD ""
#endif
#ifdef CONFIG_MODVERSIONS
#define MODULE_VERMAGIC_MODVERSIONS "modversions "
#else
#define MODULE_VERMAGIC_MODVERSIONS ""
#endif
#ifndef MODULE_ARCH_VERMAGIC
#define MODULE_ARCH_VERMAGIC ""
#endif

#define VERMAGIC_STRING 						\
	UTS_RELEASE " "							\
	MODULE_VERMAGIC_SMP MODULE_VERMAGIC_PREEMPT 			\
	MODULE_VERMAGIC_MODULE_UNLOAD MODULE_VERMAGIC_MODVERSIONS	\
	MODULE_ARCH_VERMAGIC

Как видите, здесь нет и не может быть никакой версии gcc. Да и не грузится не всегда из-за vermagic.

Может банально не хватать какого-то модуля для нормальной работы. Тогда в dmesg должно сообщать каких экспортных символов не было найдено в ядре или просто посмотреть через nm <ваш модуль>.ko, какие же там вообще есть символы. Скорее всего рыть надо в этом направлении, если vermagic сходится.

delete83 ★★
()
Ответ на: комментарий от delete83

Оппа, а какое у вас ядрышко? Когда частью моей работы была сборка нашего модуля под разные ядра версия gcc входила в vermagic. И даже по первой ссылке в гугле

http://tldp.org/LDP/lkmpg/2.6/html/x380.html

Где есть пример:

version magic '2.6.5-1.358custom 686

REGPARM 4KSTACKS gcc-3.3' should be '2.6.5-1.358 686 REGPARM 4KSTACKS gcc-3.3'

Может я отстал от жизни и gcc теперь реально не обязан совпадать?

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от DELIRIUM

Не поленился и скачал таки исходники ядра версии 2.6.5.

Действительно, в те далекие времена (кстати, сколько это по времени? 5 лет?) в vermagic записывалась версия gcc. Вот листинг vermagic.h версии 2.6.5: 

#include <linux/version.h>
#include <linux/module.h>

/* Simply sanity version stamp for modules. */
#ifdef CONFIG_SMP
#define MODULE_VERMAGIC_SMP "SMP "
#else
#define MODULE_VERMAGIC_SMP ""
#endif
#ifdef CONFIG_PREEMPT
#define MODULE_VERMAGIC_PREEMPT "preempt "
#else
#define MODULE_VERMAGIC_PREEMPT ""
#endif
#ifndef MODULE_ARCH_VERMAGIC
#define MODULE_ARCH_VERMAGIC ""
#endif

#define VERMAGIC_STRING 						\
	UTS_RELEASE " "							\
	MODULE_VERMAGIC_SMP MODULE_VERMAGIC_PREEMPT 			\
	MODULE_ARCH_VERMAGIC 						\
	"gcc-" __stringify(__GNUC__) "." __stringify(__GNUC_MINOR__)

delete83 ★★
()
Ответ на: комментарий от delete83

Ну это было не только в 2.6.5, я точно помню, что это также актуально было для всех RHEL 5й и 4й ветки, debian etch, lenny. Как с этим в актуальных версиях, не в курсе.

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от DELIRIUM

Я с этим не спорю. И не собираюсь даже пытаться искать, в какой версии ядра произошли изменения. Ответ то очень прост. Надо взять любой модуль с целевой системы и посмотреть его vermagic. И сделать надо точно такой же в своем модуле. )

delete83 ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← [cmake][macos] Несколько бинарников в один bundle
Development
нужна структура данных →