Forum Linux.noyau Comportement étrange de l'ouverture d'un device

Posté par  .
Étiquettes : aucune
0
27
jan.
2010
Bonjour,

J'ai écrit un module linux mais j'ai un comportement étrange lorsque j'essaye d'y accéder par une application.

Pour faire court : lorsque je l'ouvre avec 'cat' cela fonctionne impeccable, lorsque je l'ouvre avec une application cela ne fonctionne pas : le fichier n'existe pas dit le système.

Avec plus de détail :
mon module est un simple character device de type filesystem.

Si je fais
#strace -eopen cat /dev/my_test
......
open("/dev/my_test", O_RDONLY|O_LARGEFILE) = 3
...

Ce la fonctionne.

Maintenant mon programme qui comporte la ligne C ( compilé avec l'option -D_GNU_SOURCE pour avoir droit de faire un O_LARGEFILE) :
fbdesc = open("/dev/my_test", O_RDONLY|O_LARGEFILE );

Cela donne :
#strace -eopen myTest
...
open("/dev/my_test", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
....

Les droits sont les mêmes. Je peux alterner les cat et mon programme le comportement ne change pas.

La je suis sec .....
Une idée?
Merci

  • # Plus de contexte

    Posté par  . Évalué à 2.

    Là, comme ça, ça paraît effectivement étrange. Pourrais-tu fournir plus d'informations ?
    Genre un peu plus de contexte pour le strace, et les morceaux important de ton programme (quoique, c'est souvent dans les choses "peu importantes" que se trouve l'erreur bête qu'on avait pas vu ...)

    • [^] # Re: Plus de contexte

      Posté par  . Évalué à 1.

      Le /dev/my_test est ouvert par un module que j'ai écrit , c'est un très bête module de type filesystem :

      static struct file_operations hello_ops= {
      .read = helloRead,
      .write = helloWrite,
      .open = helloOpen,
      .release = helloRelease
      };

      Avec :

      static int helloOpen(struct inode *inode, struct file *file) {
      printk(KERN_DEBUG "hello2 open()\n");
      return 0;
      }
      Il y a aussi dans le init (avec major à 0)
      ret = register_chrdev(major,HELLO_DEV_NAME,&hello_ops);
      printk(KERN_ALERT "MAJOR HELLO2= %d\n",ret);

      Je retrouve dans le dmesg le majeur puis je crée mon /dev/my_test : mknod /dev/my_test c 254 0

      Si j'essaye de lire /dev/my_test avec cat pas de problème.
      Si avec mon programme j'essaye de lire /dev/zero par exemple il fonctionne. mais pas /dev/my_test
      J'ai regardé avec valgrind , pas de problème sur mon programme.

      Voici un programme de test minimal qui plante :

      int main(int argc, char * argv[])
      {
      int fbdesc;

      fbdesc = open("/dev/oco-out", O_RDONLY|O_LARGEFILE );
      if(fbdesc == -1)
      {
      perror("open fb");
      exit(-1);
      }

      close(fbdesc);
      exit(0);
      }

      compilé avec -g -D_GNU_SOURCE -Wall

      • [^] # Re: Plus de contexte

        Posté par  . Évalué à 2.

        Je vais sans doute dire une connerie, mais vu que t'as écrit /dev/oco-out et que tu parles de /dev/my_test autre pas, tu ne te serais pas juste trompé de fichier ? (je suppose quand même que c'est une erreur de copier/coller dans ton post, mais on sait jamais)

        • [^] # Re: Plus de contexte

          Posté par  . Évalué à 1.

          En effet, erreur de copier coller.
          Le vrai device c'est /dev/oco_out mais pour donner un nom plus explicite je l'ai appelé /dev/my_test dans mes explications.

          Le truc c'est que je copie le buffer d'un framebuffer dans un autre module puis une application vas lire a travers /dev/my_test (ou /dev/oco_out) l'image présente dans le framebuffer.

          J'ai rajouter un système de synchronisation me permettant de savoir quand une image est disponible.

          • [^] # Re: Plus de contexte

            Posté par  . Évalué à 2.

            Et le tiret à la place du underscore, c'est une erreur de copier/coller aussi ? ... (oui, j'essaye toutes les éventualités ...)

Suivre le flux des commentaires

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