Bonjour à tous. Bon pour ceux qui n'ont pas suivi, je suis en train de créer un module servant de driver pour une caméra usb. Pour cela, j'ai repris :
/usr/src/linux-2.4.20-8/drivers/usb/usb-skeleton.c, je l'ai copié dans mon répertoire de travail, et je l'ai renommé en usbcam.c.
 
Je suis donc en train de tester mon module (dans lequel j'ai renommé les fonctions skel->usbcam). La compilation de mon fichier C marche avec la ligne :
"gcc -g -O -Wall -I/usr/src/linux-2.4.20-8/include -I/usr/src/linux-2.4.20-8/drivers/usb/ -c -o usbcam.o usbcam.c"
 
Ceci me génère bien un fichier usbcam.o dans mon répertoire de travail et lorsque je fais "insmod usbcam.o", je vois bien grace à mes printk et l'affichage de /var/log/messages, que la fonction d'init de mon module est bien lancée. Le probe marche aussi quand je branche une clé usb (je n'ai pas encore les caméras) ainsi que de disconnect quand je la débranche.
 
Je voudrais pouvoir faire une petite application de test de mon module, notemment pouvoir lancer les fonctions décrites commes fops (read, write, ioctl, open, release). Mais comment rendre ce module accessible à une appli et comment linker cette appli au module ?
 
Disons que je veux faire un fichier test.c . Dois-je créer un fichier usbcam.h, que j'inclue dans test.c ? Que dois-je mettre dans ce fichier usbcam.h ?  Simplement les prototypes de fonctions ne suffit pas ... il ne connait pas les structures utilisées ... mais si je transfère les #include utilisés dans usbcam.c, vers usbcam.h, ainsi que les définitions de structures propres au driver, ben j'ai des gros soucis de compils ... suis-je sur la bonne voie ?
N'y-a-t-il pas un moyen plus simple d'utiliser simplement usbcam.o ?
 
Merci d'avance si vous pouvez me débloquer un peu !!!

Bon ben j'ai l'impression d'avancer un peu. J'ai laissé tomber le fait de créer un usbcam.h.
 
En fait, une fois mon module usbcam.o compilé et lancé, je crée un device de la facon suivante :
"mknod /dev/usb/usbcam0 c 180 200" (200 correspondant au USBCAM_MINOR_BASE de mon module )
 
Ensuite, dans mon test.c, je fais :
 
########################################
int fd;
fd = open("/dev/usb/usbcam0",O_RDWR,0);
// si erreur :
if (fd<0)
{
printf("Ouverture Failed\n" );
close(fd);
return 1;
}
// si OK :
else
{
printf("Ouverture OK\n" );
??????
return 0;
}
#######################################
 
Je pense que j'avance car sans avoir mis le close(fd), ben je ne pouvais plus tuer mon module ... car il était encore utilisé.
 
Mais je ne comprend pas deux choses :
- d'abord comment cela se fait-il que j'ai toujours une erreur à l'ouverture (Ouverture failed) ?
- ensuite, comment se passe l'appel aux fonctions de mon driver, si j'arrive à passer dans le cas Ouverture OK ? Est-ce que si je fais un ioctl par exemple, ca m'appelle la fonction usbcam_ioctl, si je fais read, ca m'appelle usbcam_read ... ???
 
Merci d'avance pour votre aide !

pour ta question du premier topic, tu n'a rien besoin d'inclure. Tu vas faire des fopen, fread, ... sur le fichier periphérique /dev/usb/usbcam0, tu n'a qu'a inclure <stdio.h>
 
avec errno, tu aurra un meilleur diagnostic d'erreur. Vérifié les permissions sur le fichier périphérique, ça m'étonnerai pas que ce soit ça ...

ça marche comme ça ... il vaut mieux appeler fread, et un maximum les fonctions de la lib C. Mais il me semble qu'il y a quelques subtilités pour l'interface usb (et pci aussi), je regarde ce soir. T'es toujours sur un noyau 2.4 ?

Oui, toujours noyau 2.4.20-8 !
 
Un grand merci à toi, c'est très cool. Ca avance pas mal. J'arrive effectivement à passer dans le open de mon module, mais je l'ai fait avec open(...) et pas fopen(...) comme tu dis. Je vais me pencher sur ta solution.
 
Et si ca passait jamais dans ouverture OK, c'est que j'y croyais tellement peu ... que j'avais même pas branché mon device ... la honte !
 
Un grand merci encore

n'est-ce pas !!!!
 
 
Par contre, ton code ne marche pas car fopen renvoit NULL si jamais l'ouverture bugue ... et non pas une valeur négative !
Faut juste corriger :
 

 
Nickel d'ailleurs le coup des errno !

 
oui oui, ça renvoie NULL    
 
et tu ne peux pas fermer un fichier que tu n'a pas pu ouvrir !

!!!
 
Vous connaitriez pas, ++ fab ou quelqu'un d'autre, un bon tutoriel en ligne sur ce sujet, car j'ai toujours des nouvelles questions qui arrivent ... et je ne trouve les réponses nullepart ...
 
... exemple : puis-je me redéfinir une structure file_operations personnelle afin d'avoir un prototype de fonction ioctl différent?

 
aux éditions O'Reilly, "les pilotes de périphériques sous Linux", il y a le bouquin et je crois que l'on peut trouver le contenu gratuitement en ligne sur leur site. A voir ...

 
je pense que non.
 
sinon, le bouquin sus-cité est bien (j'avais la version anglaise).

Oui, j'ai déjà attaqué la version anglaise trouvée ici :
http://www.xml.com/ldd/chapter/book/
...effectivement, il est bien, mais j'avais pas réussi à y trouver par exemple le fait d'appeller les procédures classiques lors du test (fopen, fread, ioctl,...) ce qui appelle en fait usbcam_open, usbcam_read, usbcam_ioctl ...
 
Merci quand même à vous !

Bon milles excuses, ce bouquin contient effectivement bon nombre de réponses à mes questions ... dommage qu'il ne soit qu'en anglais sur le web !