Accès à la mémoire du module du noyau

Deux modules de noyau différents peuvent-ils accéder à la même zone de mémoire à partir d'un appel à ioremap_nocache ()?

J'ai un pilote sans fil et un module séparé, je voudrais que le module séparé profile les valeurs de bruit sur la carte, tandis que le pilote fonctionne toujours. D'où ma question ci-dessus.

Une avenue que j'ai explorée était de démarrer un thread du noyau à partir du pilote, j'ai ensuite implémenté un sémaphore pour empêcher toute condition de concurrence résultant de la lecture / écriture simultanée dans le même espace d'adressage. J'espérais qu'un thread enfant pourrait accéder à la même zone de mémoire.

Malheureusement, cela n'a pas fonctionné comme je m'y attendais. J'apprécierais toutes suggestions.

kernel

— Radagasp
source

Pourquoi auriez-vous besoin d'un module noyau pour profiler les valeurs de bruit?

— gertvdijk

Merci pour la question, le pilote sans fil est très complexe, et modifier la périodicité de ses calibrations pourrait induire des résultats inattendus. Je devrais le faire car il ne fait que ses étalonnages pour des intervalles beaucoup trop longs pour mes besoins. Comme je sais exactement comment profiler l'appareil dans un module séparé, je suis simplement curieux de savoir si je peux accéder à la même zone de mémoire avec laquelle le pilote travaille.

— Radagasp

Veuillez modifier votre question pour inclure tous les détails sur vos tentatives / approches précédentes. Voilà comment fonctionne ce site. Ce n'est pas un forum de discussion, mais un site de questions / réponses, vous voyez?

— gertvdijk

La discussion peut comprendre des questions et des réponses, certaines bonnes et d'autres fausses - il semble que l'interprétation des règles entre les administrateurs relève de la sémantique. J'ai bien sûr mis à jour ma question.

— Radagasp

Je suppose que vous avez l'intention d'implémenter un autre module du noyau car vous pensez qu'il est plus facile de partager des données entre les modules du noyau. Mais ce n'est peut-être pas un bon choix. S'il est possible de «profiler le bruit» dans l'espace utilisateur, je pense qu'une meilleure solution est d'implémenter le «profileur» dans l'espace utilisateur.

Dans cette solution, le profileur d'espace utilisateur lit les données, effectue certains calculs et soumet le résultat.

Si cette solution est correcte, l'implémentation est la suivante.

Dans le module du noyau, il s'agit simplement d'enregistrer un périphérique char dans '/ proc' et d'implémenter les primitives 'read' et 'write'. Dans l'espace utilisateur, il suffit d'implémenter le profileur, de lire et d'écrire sur le périphérique char. Les détails et informations pour cette implémentation sont tous ici .

— vitorafsr
source

Je ne pense pas avoir tout à fait votre réponse ... si je comprends bien, j'aurais encore besoin d'écrire un module, et ce module essaierait d'accéder à la même zone de mémoire à partir d'un appel à ioremap_nocache () que l'autre module utilise. Ou dites-vous que

— j'enregistre

Bon, vous devrez implémenter un logiciel, mais pas un module. Vous devrez écrire un programme d'espace utilisateur normal, plus simple qu'un module, qui lit à partir de '/ dev / nameofdevice' et y écrit. Pas besoin d'utiliser 'ioremap_nocache ()', juste des appels système comme 'open', 'read', 'write', 'close'. Et oui, le module sans fil devra enregistrer le périphérique char '/ dev / nameofdevice' à l'intérieur, pour exposer les données à l'espace utilisateur.

— vitorafsr