Vous n'avez pas de chance d'invoquer les fonctions de l'espace utilisateur à partir du noyau, car le noyau ne connaît pas et n'est pas censé connaître les fonctions et la logique des applications individuelles de l'espace utilisateur, sans oublier que chaque application de l'espace utilisateur a sa propre mémoire mise en page, qu'aucun autre processus ni le noyau ne sont autorisés à envahir de cette manière (les objets partagés sont l'exception ici, mais vous ne pouvez toujours pas y accéder depuis l'espace du noyau). Qu'en est-il du modèle de sécurité, vous n'êtes pas censé exécuter le code de l'espace utilisateur (qui est automatiquement considéré comme un code non sécurisé dans le contexte du noyau) dans le contexte du noyau en premier lieu, car cela cassera le modèle de sécurité d'un noyau juste là dans cet instant. Maintenant, compte tenu de tout ce qui précède, ainsi que de nombreux autres motifs, vous voudrez peut-être reconsidérer votre approche et vous concentrer sur le noyau <-> IPC et les interfaces de l'espace utilisateur, le système de fichiers ou l'API d'assistance en mode utilisateur (lire ci-dessous).
Vous pouvez toutefois invoquer des applications d'espace utilisateur à partir du noyau, en utilisant l'API usermode-helper. L'article IBM DeveloperWorks suivant devrait vous permettre de commencer à utiliser l'API du noyau Linux usermode-helper :
API du noyau, partie 1 :invoquer des applications de l'espace utilisateur à partir du noyau
Je pense que le moyen le plus simple consiste à enregistrer un périphérique de caractères qui devient prêt lorsque le périphérique contient des données.
Tout processus qui essaie de lire à partir de cet appareil, puis est mis en veille jusqu'à ce que l'appareil soit prêt, puis se réveille, auquel cas il peut faire la chose appropriée.
Si vous voulez simplement signaler que vous êtes prêt, un lecteur peut simplement lire un seul octet nul.
Le programme de l'espace utilisateur aurait alors juste besoin d'exécuter un appel bloquant read(), et serait bloqué de manière appropriée, jusqu'à ce que vous le réveilliez.
Vous devrez comprendre le mécanisme de file d'attente du planificateur du noyau pour l'utiliser.
Il semble que votre ligne d'interruption soit déjà disponible dans l'espace utilisateur via gpiolib ? (/sys/class/gpio/...)
Avez-vous évalué si le déclenchement gpio edge et poll() est assez rapide pour vous ? De cette façon, vous n'avez pas à interroger l'état de l'application de l'espace utilisateur, mais le déclenchement de bord le signalera via poll(). Voir Documentation/gpio.txt dans les sources du noyau.
Si le déclenchement de bord via sysfs n'est pas assez bon, alors la bonne façon est de développer un pilote de noyau qui prend en charge la partie critique du temps et exporte les résultats vers l'espace utilisateur via une API (sysfs, nœud de périphérique, etc.).