A veces, un módulo externo utiliza símbolos exportados desde otro módulo externo . kbuild necesita tener pleno conocimiento de todos los símbolos para evitar salpicaduras de advertencias sobre símbolos indefinidos. Existen tres soluciones para esta situación.
NOTA: Se recomienda el método con un archivo kbuild de nivel superior, pero puede ser poco práctico en determinadas situaciones.
Usar un archivo kbuild de nivel superior Si tiene dos módulos, foo.ko y bar.ko, donde foo.ko necesita símbolos de bar.ko, se puede utilizar un archivo kbuild de nivel superior común, por lo tanto los módulos se compilan en la misma compilación . Considere el siguiente diseño de directorio:
./foo/ <= contains foo.ko ./bar/ <= contains bar.ko
The top-level kbuild file would then look like:
#./Kbuild (or ./Makefile): obj-y := foo/ bar/
And executing
$ make -C $KDIR M=$PWD
will then do the expected and compile both modules with full
conocimiento de los símbolos de cualquiera de los módulos.
Utilice un archivo Module.symvers adicional Cuando se genera un módulo externo, se genera un archivo Module.symvers que contiene todos los símbolos exportados que no están definidos en el kernel. Para obtener acceso a los símbolos de bar.ko, copie el archivo Module.symvers de la compilación de bar.ko en el directorio donde se construye foo.ko. Durante la construcción del módulo, kbuild leerá el archivo Module.symvers en el directorio del módulo externo , y cuando la construcción finalice, se creará un nuevo archivo Module.symvers que contiene la suma de todos los símbolos definidos y no parte del kernel
Uso "hacer" KBUILD_EXTRA_SYMBOLS variables Si no es práctico para Module.symvers copia de otro módulo, puede asignar una lista separada por espacios de archivos a KBUILD_EXTRA_SYMBOLS en su fichero de construcción. Estos archivos serán cargados por modpost durante la inicialización de sus tablas de símbolos.
Genial! Me lo perdí. Gracias Gossamer! – MirkoBanchi