Forum Linux.noyau Kernel module accédant à hidraw

Posté par  . Licence CC By‑SA.
Étiquettes :
2
15
mai
2017

Bonjour à tous.

Voilà mon problème, je suis un peu "newbie" dans le monde linux, je suis plus habitué à programmer sur micro contrôleurs.

Je me suis fait un module kernel pour communiquer avec un appareil en I2C sur mon raspberry pi.
Maintenant, ce module doit aussi communiquer avec un périphérique usb reconnu en /dev/hidraw0/

J'ai testé un soft simple et j'arrive à communiquer sans soucis avec des fonctions read/write et le configurer avec des ioctl.

Maintenant je bute un peu sur comment transférer ce code dans mon module, les fonctions read/write/ioctl n'étant pas reconnues vu qu'apparemment je ne suis pas dans l'user space.

Avez vous une idée, un exemple de kernel module communiquant avec ce type d'appareil ?

Merci !

A bientôt

  • # Je ne réponds pas à la question

    Posté par  (site web personnel) . Évalué à 2.

    Pourquoi veux tu que ce soit un module kernel ?
    Tu dois pouvoir faire ce que tu souhaites en user space, non ?

  • # Appeler directement les fonctions qui t’intéresse

    Posté par  . Évalué à 1. Dernière modification le 16 mai 2017 à 10:21.

    Si les fonctions de lecture / écriture / ioctl du driver gérant hidraw sont exposées publiquement, tu peux le appeler directement depuis ton driver à toi.

    • [^] # Re: Appeler directement les fonctions qui t’intéresse

      Posté par  . Évalué à 1.

      Salut,
      Merci de ta réponse, peux tu développer ? Car là, je ne sais vraiment pas comment faire.
      open(), read(), write() et ioctl() semblent ne pas exister dans un module kernel ?
      A bientôt

      • [^] # Re: Appeler directement les fonctions qui t’intéresse

        Posté par  . Évalué à 1.

        Ce n'est pas d'appeler les callback read / write / ioctl du driver hidraw mais d'appeler les fonctions qui sont appelées dedans:

        En reprenant ce que fait la callback de read de hidraw par exemple:

        static ssize_t hidraw_read(struct file *file, char __user *buffer, size_t count, loff_t *ppos) 
{
  ....
  len = la_fonction_qui_m_interesse(&data);
  copy_to_user(buffer, data, len);
  ...
}

        Et donc d'appeler directement la_fonction_qui_m_interesse … Mais en fait je vois que ça ne peut pas marcher, vue qu'en vrai les callback de hidraw mettent à jour des structures internes qui ne sont pas exposées …. Donc non, ça va pas marcher !

  • # OK on l'as tous eut cette idée

    Posté par  . Évalué à 2.

    Mais faire des accès fichiers dans le kernel est une TRES mauvaise pratique.
    Ce qui ne veut pas dire que ce n'est pas possible avec sys_call voir ici
    Mais honnêtement, je feras autrement, un simple daemon en user-space coordonnant l'i2c et ton module serait plus simple à mettre au point et à écrire. Et convertir ton soft existant en daemon est assez simple.

  • # ca avance

    Posté par  . Évalué à 1.

    Bon, j'ai un peu avancé.
    J'arrive donc à ouvrir mon périphérique grâce à un filp_open en prenant garde à bien utiliser get_fs et set_fs.
    Je peux lui faire des requêtes ioctl grâce à un hidraw_file->f_op->unlocked_ioctl(hidraw_file,cmd,arg)
    Mais par contre, dès que la commande du ioctl demande à écrire (config du périf), j'ai un plantage du système alors qu'une lecture fonctionne parfaitement (lecture id, etc).
    Par exemple, une commande HIDIOCGRAWNAME fonctionne par contre HIDIOCSFEATURE me plante le pi…
    Une petite idée ?
    A bientôt

    • [^] # Re: ca avance

      Posté par  . Évalué à 1.

      Vu comme ça, ça sent le deadlock !

      Et puis je pense que ça ne soit pas très safe comme méthode : appeler les ioctls / read / write sans passer par l'API, c'est un peu casse gueule … D'instinct, je vérifierais si ton callback unlocked_ioctl soit bien appelé avec les bons locks verrouillés (ou déverrouillés) !

      Ton kernel a-t-il eu le temps de sortir son kernel panic ?

      Bref, comme dit plus haut, moi je ferrais en les traitements des données en user-space et tes drivers ne faisant qu'exposer les donnés des I/O ….

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.