0

Je suis en train de compiler un pilote linux externe avec la ligne ci-dessous dans une plate-forme existante en utilisant de nombreuses dépendances (comme les bibliothèques):Comment construire un module linux externe qui utilise une bibliothèque personnalisée

obj-m += mydriver.o 
    KDIR ?= $(OUT_DIR) 
    default: 
     $(MAKE) -C $(KDIR) M=$$PWD 
    clean: 
     $(MAKE) -C $(KDIR) M=$$PWD clean 
    modules: 
     $(MAKE) -C $(KDIR) M=$$PWD modules 

I J'ai remarqué que cela invoque le noyau Makefile avec crée des fichiers objets et fait le lien afin de préparer un "module" .ko chargeable avec linux. Mais si, je dois utiliser une bibliothèque spécifique (par exemple my_library.a.): Comment puis-je empêcher le makefile Linux de prendre en compte cette bibliothèque supplémentaire lors de la liaison tous les fichiers objet

Appendice: 

My_library.a est un code source C++ contient des fonctions qui accèdent aux registres FPGA afin de rapporter quelques données utiles. Puis my_driver (puisqu'il s'agit d'une source de code C, j'ai dû créer une interface C à partir de my_library.a) préparera les appels système de base accessibles à partir d'une application d'espace utilisateur. En bas de la ligne, my_driver lit à partir de FPGA avec 8khz, grâce à my_library.a via une interface C et rend les données lisibles pour l'espace utilisateur APP.

Cheers, Sahbi

+0

Que * exactement * est votre 'my_library.a'? Veuillez éditer votre question pour l'améliorer et être spécifique. –

+0

Et que fait exactement votre module? Quel genre de pilote développez-vous? –

+0

Il semble que vous mélangez des concepts de pilotes d'espace utilisateur et d'espace noyau. – 0andriy

Répondre

0

Très probablement, vous ne pouvez pas utiliser une bibliothèque externe au niveau de l'application ou libmy.amy_library.a dans un module du noyau (ou le code du noyau). De telles bibliothèques sont généralement construites au-dessus du C standard library (par exemple parce qu'elles utilisent <stdio.h> à fprintf ou <stdlib.h> à malloc), ce qui n'existe pas pour le code noyau.

Les modules du noyau conceptuels et le code noyau sont autoportant (c'est-à-dire pas au-dessus de la bibliothèque standard C).

Notez que les conventions d'appel ABI & peuvent être différentes dans le code noyau et dans le code d'application. Et certainement, certaines fonctions standard (comme malloc, printf, snprintf ....) peuvent ne pas exister à l'intérieur du noyau. le code noyau BTW ne peut pas utiliser à virgule flottante, etc ...

Bien sûr, vous pourriez relier votre propre bibliothèque du noyau (de vos propres fichiers objets du noyau), mais qui est souvent pas la peine.

(une exception improbable pourrait être une bibliothèque externe qui ne réalise aucune fonction standard C et ne calcule pas avec virgule flottante, mais cela ne se produit pas dans pracice)

Enfin, la sagesse conventionnelle est pour éviter d'avoir besoin de beaucoup de code noyau. Donc, vous devriez envisager d'avoir un certain processus utilisateur en mode auxiliaire. Voir netlink(7).

Vous devriez probablement revoir votre pilote pour éviter d'avoir besoin d'une bibliothèque externe. Depuis que vous avez lu le FPGA à seulement 8KHz, cette partie de votre code pourrait se trouver dans l'espace utilisateur au-dessus des appels système existants.

Notez que le code du noyau ne peut pas être écrit en C++