Sie haben Pech beim Aufrufen von User-Space-Funktionen aus dem Kernel, da der Kernel nicht über einzelne User-Space-Anwendungsfunktionen und -Logik Bescheid weiß und nicht wissen soll, ganz zu schweigen davon, dass jede User-Space-Anwendung ihren eigenen Speicher hat Layout, dass kein anderer Prozess oder der Kernel auf diese Weise eindringen darf (gemeinsame Objekte sind hier die Ausnahme, aber Sie können das immer noch nicht aus dem Kernel-Bereich anzapfen). Was ist mit dem Sicherheitsmodell, Sie sollten in erster Linie keinen User-Space-Code (der im Kernel-Kontext automatisch als unsicherer Code gilt) im Kernel-Kontext ausführen, da dies das Sicherheitsmodell eines Kernels direkt dort brechen würde dieser Augenblick. In Anbetracht all der oben genannten und vieler anderer Motive möchten Sie vielleicht Ihren Ansatz überdenken und sich auf Kernel <-> User-Space IPC und Schnittstellen, das Dateisystem oder die Benutzermodus-Hilfs-API (lesen Sie unten) konzentrieren.
Sie können User Space-Apps jedoch über den Kernel aufrufen, indem Sie die Usermode-Helper-API verwenden. Der folgende IBM DeveloperWorks-Artikel soll Ihnen den Einstieg in die Verwendung der Usermode-Helper-Linux-Kernel-API erleichtern:
Kernel-APIs, Teil 1:Aufrufen von User-Space-Anwendungen aus dem Kernel
Ich denke, der einfachste Weg ist, ein Zeichengerät zu registrieren, das bereit ist, wenn das Gerät einige Daten hat.
Jeder Prozess, der versucht, von diesem Gerät zu lesen, wird dann in den Ruhezustand versetzt, bis das Gerät bereit ist, und dann aufgeweckt, an welchem Punkt es das Richtige tun kann.
Wenn Sie nur die Bereitschaft signalisieren möchten, könnte ein Lesegerät nur ein einzelnes Nullbyte lesen.
Das Userspace-Programm müsste dann nur einen blockierenden read()-Aufruf ausführen und wäre entsprechend blockiert, bis Sie es aufwecken.
Sie müssen den Warteschlangenmechanismus des Kernel-Schedulers verstehen, um dies zu verwenden.
Klingt so, als ob Ihre Interrupt-Leitung bereits über gpiolib für den Userspace verfügbar ist? (/sys/class/gpio/...)
Haben Sie Benchmarking durchgeführt, ob gpio edge triggering und poll() schnell genug für Sie sind? Auf diese Weise müssen Sie den Status nicht von der Userspace-Anwendung abfragen, sondern das Edge-Triggering wird ihn über poll() melden. Siehe Documentation/gpio.txt im Kernel-Quelltext.
Wenn das Flankentriggern über sysfs nicht gut genug ist, dann ist der richtige Weg, einen Kerneltreiber zu entwickeln, der sich um den zeitkritischen Teil kümmert und die Ergebnisse über eine API (sysfs, Geräteknoten usw.) in den Userspace exportiert.