Vous aurez beaucoup de difficulté à ajouter une nouvelle interface dans/proc /. Les développeurs du noyau sont mécontents qu'il soit devenu un dépotoir pour diverses interfaces, et à moins que vous ne modifiiez quelque chose sur les processus via/proc/pid /, je pense que vous aurez du mal à convaincre la communauté du noyau de l'accepter.
Un fichier de périphérique dans/dev/peut être acceptable, même pour les modules qui ne sont pas réellement des pilotes de périphérique. (par exemple,/dev/kvm,/dev/pts,/dev/ecryptfs,/dev/fuse,/dev/kmsg,/dev/ptmx, etc.) Cependant, les fichiers de périphériques sont trop souvent plus faciles à manipuler avec ioctl (), et je pense que vous avez raison de l'éviter si vous le pouvez.
La tendance actuelle dans les cercles du noyau est sysfs ou systèmes de fichiers personnalisés. L'approche sysfs est basée sur une sémantique à valeur unique par fichier, destinée à être manipulée avec echo et cat. C'est merveilleux pour les utilisateurs si cela fonctionne pour vous. Les systèmes de fichiers personnalisés vous permettent d'écrire des interfaces binaires très spécifiques, et fs/libfs.c devrait vous aider à écrire votre propre système de fichiers selon vos besoins. (Je ne connais personne qui a utilisé configfs, mais j'ai toujours pensé qu'il semblait soigné Peut-être que cela conviendrait à votre module?)
Comme sarnold souligne les objets représentés dans/dev/ne doivent pas être " vrais "appareils". Si votre pilote expose une interface de type POSIX (ouvrir/lire/écrire), il n'y a pas de raison de ne pas l'utiliser. Quel type de communication envisagez-vous d'avoir entre l'espace utilisateur et l'espace noyau? – stsquad
Une partie de notre logiciel effectue trop d'appels système, ce qui affecte les performances du système. Pour éviter le fardeau de ces appels, nous prévoyons de le déplacer dans l'espace noyau. Essentiellement, la communication entre le noyau et l'espace utilisateur impliquera de gros transferts de données. J'apprécierais fortement si quelqu'un peut suggérer n'importe quelle autre technique pour ce problème. – binW
Il est peu probable que les appels système soient significativement plus rapides à partir de l'espace noyau - du moins, pas assez pour compenser le coût supplémentaire de la copie de grandes quantités de données vers et depuis l'espace noyau. Cela dit, étudiez un fichier de périphérique qui implémente 'mmap'. – caf