Czasami moduł zewnętrzny zastosowania eksportowane symbole z innego modułu zewnętrznego. kbuild musi posiadać pełną wiedzę o wszystkich symbolach , aby uniknąć wypluwania ostrzeżeń o niezdefiniowanych symbolach. W tej sytuacji istnieją trzy rozwiązania: .
UWAGA: Metoda z plikiem kbuild najwyższego poziomu jest zalecana, ale w pewnych sytuacjach może być niepraktyczna.
Użyj plik kbuild najwyższego poziomu Jeśli masz dwa moduły, foo.ko i bar.ko, gdzie foo.ko potrzebuje symboli z bar.ko, można użyć pliku kbuild wspólny najwyższego poziomu więc zarówno moduły są kompilowane w tej samej kompilacji co . Rozważmy następujący układ katalogu:
./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
znajomość symboli z dowolnego modułu.
Użycie dodatkowego pliku Module.symvers Po zbudowaniu modułu zewnętrznego generowany jest plik Module.symvers zawierający wszystkie wyeksportowane symbole , które nie są zdefiniowane w jądrze. Aby uzyskać dostęp do symboli od bar.ko, skopiuj plik Module.symvers z kompilacji z bar.ko do katalogu, w którym zbudowano foo.ko. Podczas budowania modułu, kbuild odczyta plik Module.symvers z katalogu zewnętrznego modułu , a po ukończeniu kompilacji zostanie utworzony nowy plik Module.symvers zawierający sumę wszystkich symboli zdefiniowanych, a nie części jądra.
użycie „make” Zmienna KBUILD_EXTRA_SYMBOLS Jeśli jest to niepraktyczne kopiowanie Module.symvers z innego modułu, można przypisać przestrzeń oddzielone listę plików do KBUILD_EXTRA_SYMBOLS w pliku kompilacji. Pliki te zostaną załadowane przez modpost podczas inicjalizacji jego tablic symboli.
Świetnie! Tęsknie za tym. Dziękuję Gossamer! – MirkoBanchi