Débuter en kernel-programmation avec un driver en mode caractères

Bruggemann Eddie

- Titre : Débuter en kernel-programmation avec un driver en mode caractères

- Auteur : Bruggemann Eddie

- Parution : 28 mars 2014

- Licence : Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright ® 2016 Bruggemann Eddie. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Introduction

- I-A. Disposer des sources du noyau

- I-B. Spécificités du GNU C

- I-C. Connaissance de l'outil make

- II. Écriture et chargement d'un kernel-module

- II-A. Introduction a un kernel-module

- II-B. Structure d'un module

- II-C. Écriture, compilation et insertion dans le noyau:

- III. Écriture d'un driver

- III-A. Introduction à un driver

- III-B. Fonctions nécessaires

- III-C. Écriture, compilation et insertion dans le noyau:

- IV. La structure file_operations

- IV-A. Introduction a la structure file_operations

- IV-B. Description de la fonction open()

- IV-C. Description de la fonction release()

- IV-D. Description de la fonction read()

- IV-E. Description de la fonction write()

- IV-F. Un exemple Hello world

- V. Un exemple de driver de périphérique virtuel

- V-A. Introduction à l'exemple avancé

- V-B. Code d'un driver de périphérique virtuel

I - Introduction

I-A - Disposer des sources du noyau

Pour écrire du code pour le noyau, il faut disposer des sources de celui-ci car le noyau que utilise votre système Linux n'est rien d'autre qu'un gros fichier exécutable, lancer au boot, situer dans le dossier /boot.

Les sources de votre noyau actuel sont présentes dans le dossier du système :/usr/src/linux-headers-$(uname -r)/ de votre système.

Celui-ci contient les dossiers suivants sous Ubuntu:

/arch : Contient un dossier pour ce qui est spécifique a une architecture.

/block : Driver en mode block.

/crypto : Cryptage.

/Documentation : Documentation (Il faut la générer comme nous allons le voir).

/drivers : Drivers.

/firmware : Firmwares.

/fs : Système de fichier.

/include : Fichiers d'en-tête a inclure pour la programmation noyau.

/init : Initialisation du kernel.

/ipc : IPC (Inter Process Communication).

/Kbuild :

/Kconfig :

/kernel : Noyau du noyau.

/lib : Bibliothèques utilitaires.

/Makefile : Fichier de compilation du noyau avec l'outil make.

/mm : Gestion de la mémoire (Memory Management).

/Module.symvers :

/net : Résaux.

/samples : Examples de tracepoints.

/scripts : Scripts de génération du noyau.

/security : Sécurité.

/sound : Audio.

/tools : Outils d'analyse de performances.

/ubuntu : Ubuntu.

/usr : User software pour l'initialisation du système de fichiers.

/virt : Virtualisation.

Pour générer la documentation sous Ubuntu : Le paquet docbook-utils est requis.

Sous Ubuntu, la génération de la documentation n'est possible qu'avec les sources téléchargées avec la commande :

1. $ sudo apt-get source linux-image-$(uname -r)

Ensuite, il faut se placer dans le dossier des sources - il existe 3 commandes chacune pour un format de sortie différents afin de générer la documentation :

1. $ sudo make pdfdocs

2. $ sudo make psdocs

3. $ sudo make htmldocs

La documentation générer se trouve dans le format choisi dans le dossier : /Documentation/DocBook/

I-B - Spécificités du GNU C

Le noyau n'est pas écrit en C ordinaire mais en GNU C qui est une version optimisée du langage C.

Si vous maîtrisez le langage C vous n'aurez aucun mal à assimiler les différences.

Il faut savoir qu'il ne vous sera pas possible de disposer des fonctions de la libc que vous connaissez comme dans un programme ordinaire, ni de compiler votre programme ni notre driver comme un programme ordinaire.

Mais le kernel vous met à disposition certaines fonctions analogues à celles de la libc pour certaines et bien d'autres qui sont spécifiques au noyau.

! Avec les changements de versions du noyau, les fonctions et les fichiers d'inclusion que vous utiliserez évoluent, il faut essayer de maintenir la rétrocompatibilité, mais il n'y a pas de garantie.

Notez que pour compiler notre driver, nous utiliseront l'outil make pour effectuer le linkage avec les sources du noyau.

Les spécificités du GNU C sont :

- Non utilisation des nombres à virgule flottante pour des questions de précisions :
Car il faut savoir que selon l'architecture ceux-ci sont codés autrement, malgré le fait que le kernel fournit les types de données universelles pour la programmation noyau, mais les floats ne sont pas de la partie.

- Programmation orientée objet (P.O.O) :
Les données et les fonctions doivent être strictement séparées. Les structures emploient beaucoup de pointeurs et sont définies comme propres au noyau dans un esprit de P.O.O., dont certaines sont écrites en langage d'assemblage : l'assembleur. Il existe notamment beaucoup de macros.

- Emploi de goto :
Même si on ne les retrouve pas souvent dans les programmes C actuels ils sont légions dans l'écriture de driver, car ils permettent entre autre de sauter dans un bout de codes afin de dé-initialiser des données en cas d'erreur.

- Séparation de l'espace d'adressage :
La mémoire est scindée en 2 espaces d'adressage distinct concernant les drivers et la programmation noyau :

- Un espace d'adressage utilisateur (user-space).

- Un espace d'adressage noyau (kernel-space).

Nous effectueront les translations d'adresses nécessaires au transfert d'un espace d'adressage à un autre dans le cadre de l'application cliente du driver.
D'ailleurs, ces deux espaces sont protégés l'un contre l'autre.

- Petites piles (stack) :
Le noyau utilise des stack de 2 pages dont la taille dépend de l'architecture.

- Architecture 64 bits : page de 8 K bytes * 2.

- Architecture 32 bits : page de 4 K bytes * 2.

- Importance de la synchronisation des données.

- Utilisation de fonction inline pour l'optimisation.

- Utilisation de l'assembleur de façon inline.

- Importance de la portabilité :
Pour cela il existe un répertoire spécifique propre à chaque architecture prise en charge par le noyau Linux. Pour les choses variant d'une architecture à une autre, par exemple la définition des appels systèmes.

I-C - Connaissance de l'outil make

L'outil make permet l'automatisation de la compilation d'un programme en permettant entre autre de définir les conditions sous lesquelles une commande sera lancée et de définir des variables. Nous allons nous en servir ici afin d'effectuer le linkage vers les sources du noyau et générer le fichier module de notre driver.

! Il faut faire attention aux tabulations car make ne supporte pas les espaces remplaçant celles-ci.

Le fichier source est nommé driver.c et doit être situé dans un dossier, dont le nom ne porte pas à confusion Linux (évitez les caractères non-ASCII et espaces) et l'outil make. Ce dossier sera nommé driver.

Le fichier suivant doit être nommé Makefile afin que la commande make reconnaisse notre fichier de compilation.

1. obj-m += driver.o

2. KERNELDIR ?= /lib/modules/$(shell uname -r)/build

3. PWD := $(shell pwd)

4. default:

5. $(MAKE) -C $(KERNELDIR) M=$(PWD) modules

6. clean :

7. $(MAKE) -C $(KERNELDIR) m=$(PWD) clean

Suite à quoi nous lançons la commande make qui reconnaît le fichier de compilation nommé Makefile:

1. $ cd driver

2. $ ls

3. driver.c   Makefile

4. $ sudo make

5. make -C /lib/modules/3.11.0-18-generic/build M=/home/edward/Bureau/driver modules

6. make[1]: entrant dans le répertoire « /usr/src/linux-headers-3.11.0-18-generic »

7. CC [M]  /home/edward/Bureau/driver/driver.o

8. Building modules, stage 2.

9. MODPOST 1 modules

10. CC      /home/edward/Bureau/driver/driver.mod.o

11. LD [M]  /home/edward/Bureau/driver/driver.ko

12. make[1]: quittant le répertoire « /usr/src/linux-headers-3.11.0-18-generic »

13. $ ls

14. driver.c   driver.mod.c  driver.o  modules.order

15. driver.ko  driver.mod.o  Makefile  Module.symvers

II - Écriture et chargement d'un kernel-module

II-A - Introduction a un kernel-module

Dans ce premier bout de code (qui est un module chargeable à chaud) à l'opposé d'insérer le code dans le noyau lors de la compilation.

Nous allons utiliser une unique fonction du kernel qui permet d'écrire dans le fichier de log de celui-ci : /var/log/kern.log dont la fin est affichable avec la commande dmesg.

La fonction printkprintf() (print kernel) qui est analogue à la fonction printf() dont le flux de sortie est le fichier de log et qui a pour prototype :

1. int printk(const char *fmt, ...) ;

Dans ce fichier on peut insérer la nature du message dans les logs du noyau, car il faut bien justifier la notification grâce aux constantes suivantes :

1. #define KERN_EMERG      "<0>"           /* System unusable      */

2. #define KERN_ALERT      "<1>"           /* Need intervention    */

3. #define KERN_CRIT       "<2>"           /* System critic error  */

4. #define KERN_ERR        "<3>"           /* Sytem error occur    */

5. #define KERN_WARNING    "<4>"           /* Warning              */

6. #define KERN_NOTICE     "<5>"           /* Notice               */

7. #define KERN_INFO       "<6>"           /* Information          */

8. #define KERN_DEBUG      "<7>"           /* Debugging            */

De la manière suivante :

1. printk(KERN_DEBUG "Here is an message in the kernel logs\n") ;

À noter que selon la nature du message et la présence du caractère linefeed ('\n') l'écriture peut être différée.

Il existe aussi une fonction pour allouer dynamiquement de la mémoire kmalloc, à la manière de malloc, défini dans <linux/slab.h> qui a pour prototype :

void *kmalloc(size_t size, gfp_t flags);

Dont le premier argument définis le nombre de bytes à allouer limité a 128 K Bytes, pour de plus grands espaces mémoires il faut se tourner vers la fonction vmalloc() qui alloue de la mémoire de façon virtuel sachant que l'espace d'adressage d'un module est limité à PAGE_SIZE fois 2.

Le deuxième argument induit le comportement de la fonction et dont les principales valeurs définies dans <linux/mm.h>, sont :

GFP_USER  : Alloue de la mémoire pour l'utilisateur.

La fonction peut dormir.

GFP_KERNEL  : Allocation de mémoire kernel normal

en essayant de puiser dans la réserve de mémoire allouer au module.

La fonction peut dormir.

FP_ATOMIC  : Allocation sans dormir.

Pour des fonctions ou cela n'est pas permis

comme dans un interrupt handler.

La fonction retourne un pointeur sur l'espace mémoire alloué ou NULL en cas d'erreur.

L'espace mémoire alloué doit être libéré avec la fonction définis dans <linux/slab.h> :

void kfree(const void *)

II-B - Structure d'un module

Un module chargeable n'a pas de fonction main() mais un point d'entrée et de sortie correspondants à l'action d'accomplir quand on charge ou décharge le module.

Le point d'entrée d'un module peut se faire en définissant une fonction :

1. int init_module(void)

2. {

3. return 0 ; /* Le code de retour est important */

4. }

Et un point de sortie :

1. void cleanup_module(void)

2. {

3. return ;

4. }

Si l'on respecte strictement le nommage du point d'entrée et de sortie la fonction init_module sera appelée automatiquement lors du chargement du module, et la fonction cleanup_module au déchargement du module.

La fonction init_module sert à initialiser les ressources nécessaires au module, donc aussi à faire des tests pour l'initialisation ou l'enregistrement par le noyau d'un driver - par exemple : le sort du module dépend de son code de retour ; si celui-ci est différent de zéro le module ne sera pas chargé et la fonction cleanup_module sert a dé-initialiser les données et donc à nettoyer, d'où son nom.

Finalement, je précise qu'il est nécessaire de définir la licence du module afin que celui-ci soit chargeable par la macro: MODULE_LICENSE() ;

qui accepte pour valeur définis dans <linux/module.h>:

« GPL » [GNU Public License v2 or later]

« GPL v2 » [GNU Public License v2]

« GPL and additional rights » [GNU Public License v2 rights and more]

« Dual BSD/GPL » [GNU Public License v2or BSD license choice]

« Dual MIT/GPL » [GNU Public License v2 or MIT license choice]

« Dual MPL/GPL » [GNU Public License v2 or Mozilla license choice]

« Proprietary » [Non free products]

II-C - Écriture, compilation et insertion dans le noyau:

Voici le code source du fichier module1.c :

1. #include <linux/module.h>

3. MODULE_LICENSE("GPL") ;

4. MODULE_DESCRIPTION("Module structure demonstration") ;

5. MODULE_AUTHOR("mrcyberfighter") ;

7. int init_module(void)

8. {

9. printk(KERN_DEBUG "Module inserted in kernel throught insmod !!!\n") ;

10. return 0 ;

11. }

13. void cleanup_module(void)

14. {

15. printk(KERN_DEBUG "Module remove from kernel throught rmmod  !!!\n") ;

16. return ;

17. }

Nous le compilons avec le fichier de compilation automatisé Makefile suivant :

1. obj-m += module1.o

2. KERNELDIR ?= /lib/modules/$(shell uname -r)/build

3. PWD := $(shell pwd)

4. default:

5. $(MAKE) -C $(KERNELDIR) M=$(PWD) modules

6. clean :

7. $(MAKE) -C $(KERNELDIR) m=$(PWD) clean

9. $ sudo make

10. make -C /lib/modules/3.11.0-18-generic/build M=/home/edward/Bureau/dossier modules

12. make[1]: entrant dans le répertoire « /usr/src/linux-headers-3.11.0-18-generic »

14. CC [M]  /home/edward/Bureau/dossier/module1.o

15. Building modules, stage 2.

16. MODPOST 1 modules

17. CC      /home/edward/Bureau/dossier/module1.mod.o

18. LD [M]  /home/edward/Bureau/dossier/module1.ko

20. make[1]: quittant le répertoire « /usr/src/linux-headers-3.11.0-18-generic »

21. $ ls

22. Makefile   module1.ko     module1.mod.o  modules.order

23. module1.c  module1.mod.c  module1.o      Module.symvers

Puis nous procédons au chargement dans le noyau du module :

1. $ sudo insmod module1.ko

Vérifions si le module est présent dans le noyau :

1. $ lsmod

2. Module                  Size  Used by

3. module1                12426  0

4. ...

Regardons les métadonnées du module :

1. $ modinfo module1.ko

2. filename:       /home/edward/Bureau/module/module1.ko

3. author:         mrcyberfighter

4. description:    Module structure demonstration

5. license:        GPL

6. srcversion:     6941103565A089C4B575D10

7. depends:

8. vermagic:       3.11.0-18-generic SMP mod_unload modversions

Puis déchargeons le module :

1. $ sudo rmmod module1.ko

Et finalement regardons si le module a écrit dans les logs :

1. $ dmesg

2. ...

3. [ 4264.823025] Module inserted in kernel throught insmod !!!

4. [ 4587.017096] Module remove from kernel throught rmmod  !!!

III - Écriture d'un driver

III-A - Introduction à un driver

Il existe 2 types de drivers :

- Les drivers en mode caractères.

- Les drivers en mode bloc.

Ils sont soit chargeables à chaud dans le noyau grâce à la fonction insmod ou insérer dans le noyau à la compilation.

Un driver contrôle le périphérique. Dans notre cas nous souhaitons contrôler un périphérique virtuel, avec un driver en mode caractères. Il nous faudra donc créer un périphérique virtuel (un fichier spécial en mode caractères) dans le dossier /dev/.

III-B - Fonctions nécessaires

Pour cela il faut procéder aux étapes suivantes :

1. Attribuer un numéro majeur et mineur qui identifiera le périphérique que nous souhaitons contrôler :
Le numéro peut être défini :
de manière statique en demandant le numéro majeur que nous souhaitons, mais il faut savoir que le numéro majeur est codé sur un byte non-signé dans la plage de 0-255.
Seules les plages suivantes peuvent être utilisées :

- 60 - 63.

- 120 - 127

- 240 - 255

Le numéro ne doit pas être attribué déjà, vérifiez en lisant le fichier /proc/devices.
$ cat /proc/devices
de manière dynamique en laissant le noyau réserver un numéro majeur garantit valide et non-attribué.

2. Réserver le numéro de périphérique en mode caractère.
En réservant au même temps que l'allocation mémoire du périphérique avec la fonction :
int alloc_chrdev_region(dev_t major,
unsigned int minor,
unsigned int minor_numbers,
const char *name) ;
qui renvoie 0 en cas de succès.

3. Allouer de la mémoire pour instancier notre objet driver avec la fonction :
Avec la fonction : void *cdev_alloc(void) ; qui renvoie un pointeur de type struct cdev sur l'objet périphérique en cas de succès sinon un pointeur NULL.

4. Lier l'objet périphérique avec une structure de type file_operations qui permet de prendre en charge les différentes actions que peuvent entreprendre le programme client du driver dont nous reparleront.

5. Lier l'objet driver au numéro référençant le périphérique par la fonction :
int cdev_add(struct cdev *driver_object, dev_t dev_num, unsigned int major) ;

6. Créer une classe de notre périphérique avec la macro :
class_create(owner, name)

1. Créer celui-ci finalement et l'enregistrer dans le système de fichier /dev/ grâce à la fonction :
struct device *device_create(struct class *cls,
struct device *parent,
dev_t devt,
void *drvdata,
const char *fmt,...)

2. Détruire les ressources créées en cas d'erreur et retourner un code d'erreur grâce à un saut avec un goto lors d'un contrôle d'un code de retour :

- Par la fonction :

void unregister_chrdev_region(dev_t dev_num,unsigned int minor_count) ;
On restitue l'espace alloué pour notre périphérique et la référence au numéro majeur ayant minor_count numéros mineurs.

- Par la fonction :

kobject_put(&driver_object->kobj) ;
On restitue l'espace alloué à l'objet driver en décrémentant à zéro la référence dans le noyau.

- On peut retourner un code d'erreur -EIO.

3. Détruire les ressources créées dans la fonction cleanup_module() :
Grâce aux fonctions suivantes :
void device_destroy(struct class *cls, dev_t dev_num);
qui détruit le périphérique virtuel représenté par la classe du périphérqiue cls lier au numéro majeur dev_num.
void class_destroy(struct class *cls);
qui détruit la classe du périphérique virtuel.
void cdev_del(struct cdev *);
qui libère l'espace alloué à la structure du driver.
void unregister_chrdev_region(dev_t dev_num, unsigned int minor_count) ;
qui restitue l'espace alloué pour notre périphérique et la référence au numéro majeur ayant minor_count numéros mineurs.

III-C - Écriture, compilation et insertion dans le noyau:

Assez de théorie - en pratique cela donne le code suivant :

1. #include <linux/module.h>  /** MODULE_LICENSE &&

2. MODULE_DESCRIPTION &&

3. MODULE_AUTHOR                 */

5. #include <linux/cdev.h>    /** cdev_del() &&

6. cdev_add() &&

7. cdev_alloc()                  */

9. #include <linux/device.h>  /** class_create() &&

10. device_create()  &&

11. device_destroy()              */

13. #include <linux/fs.h>      /** alloc_chrdev_region() &&

14. unregister_chrdev_region()    */

16. MODULE_LICENSE("GPL") ;

17. MODULE_DESCRIPTION("Driver creating as module.") ;

18. MODULE_AUTHOR("mrcyberfighter") ;

20. #define DEVICE_NAME "devname"       /** Device name   */

22. static dev_t dev_num ;              /** Major number  */

23. static struct cdev *driver_object ; /** Driver object */

24. static struct class *device_class ; /** Device class  */

27. static int __init mod_init(void)

28. {

30. static int minor=0 ;

31. static int minor_numbers=1 ;

33. printk(KERN_DEBUG "start device creating\n") ;

35. if (alloc_chrdev_region(&dev_num,minor,minor_numbers,DEVICE_NAME) < 0)

36. {

37. /** Allocate space for device and major number dev_num

38. with minor number minor and minor_numbers count

39. and as device name devname                          */

41. printk(KERN_DEBUG "Device number and space alloctating error !!! \n") ;

42. return -EIO ;

43. }

45. driver_object=cdev_alloc() ; /** Driver space allocating and

46. instantiation as struct cdev object. */

48. if (driver_object == NULL)

49. {

50. goto free_device_number ;

51. }

53. driver_object->owner=THIS_MODULE ;

56. if (cdev_add(driver_object,dev_num,1))

57. {

58. /** register the driver object to the kernel with the device number  dev_num and counts of minor numbers 1 */

59. goto free_device ;

60. }

62. device_class=class_create(THIS_MODULE,DEVICE_NAME) ;

63. /** create new device class      */

65. device_create(device_class,NULL,dev_num,NULL,"%s",DEVICE_NAME) ;

66. /** register device in /dev/  filesystem  */

68. if (device_class == NULL)

69. {

70. printk(KERN_DEBUG "Device class creating error !!!\n") ;

71. goto free_device ;

72. }

74. printk(KERN_DEBUG "Device successfull created !!!\n") ;

75. return 0 ;

77. /** error handling goto ; */

78. free_device :

79. printk(KERN_DEBUG  "Driver registering error or\n"

80. "Device class creation error.\n"

81. "Must free allocated space for device.\n") ;

82. kobject_put(&driver_object->kobj) ;

84. free_device_number :

85. printk(KERN_DEBUG "chrdev registering error !!!\n") ;

86. unregister_chrdev_region(dev_num,1) ;

87. return -EIO ;

88. }

90. static void __exit mod_exit(void)

91. {

93. device_destroy(device_class,dev_num) ;

94. /** destroy device */

96. class_destroy(device_class) ;

97. /** destroy device class */

99. cdev_del(driver_object) ;

100. /** free driver_object memory space */

102. unregister_chrdev_region(dev_num,1) ;

103. /** unregister dev_t dev_num and minors count 1 */

105. printk(KERN_DEBUG "Device destruction succesfull !!!\n") ;

106. return ;

108. }

110. module_init(mod_init) ; /** Register init_module macro.    */

111. module_exit(mod_exit) ; /** Register cleanup_module macro. */

Remarquez que nous n'avons pas utilisé la règle de nommage des fonctions d'initialisation (init_module) et de dé-initialisation (cleanup_module ) et l'ajout d'un mot-clef aux fonctions d'initialisation et de dé-initialisation sous forme de : __exit __init qui servent à la spécification de l'allocation mémoire du noyau des fonctions. Notez simplement que __init et __exit sont à placer devant le nom de la fonction - il existe d'autres spécificateurs notamment pour les variables et fonctions d'un driver pour un device hotplugable.

Ici elles n'ont pas de répercussion pour un module chargeable mais sont une bonne habitude à prendre.

Nous nous servons des macros module_init() et module_exit() qui servent à référencer les fonctions d'initialisation et de dé-initialisation afin que l'on puisse les nommer comme nous le souhaitons.

Après exécution du fichier Makefile correspondant au fichier driver.c, on charge le module-driver grâce a la fonction insmod et l'on consulte le fichier /proc/devices qui répertorie les périphériques et est divisé en 2 parties :

- Les périphériques en mode caractères.

- Les périphériques en mode bloc.

1. $ sudo make

2. $ sudo insmod driver.ko

3. $ cat /proc/devices

4. Character devices:

5. 1 mem

6. ...

7. 250 devname

8. ...

9. 254 rtc

11. Block devices:

12. 1 ramdisk

13. ...

14. 254 mdp

on s'aperçoit de la création de notre périphérique « devname » avec comme numéro majeur 250.

1. $ sudo rmmod driver.ko

2. $ cat /proc/devices

3. Character devices:

4. 1 mem

5. ...

6. 254 rtc

8. Block devices:

9. 1 ramdisk

10. ...

11. 254 mdp

Après déchargement du module-driver « devname » n'est plus présent comme périphérique.

IV - La structure file_operations

IV-A - Introduction a la structure file_operations

Afin de lier notre driver aux requêtes d'un programme client, il existe une structure définie dans : <linux/fs.h>

Qui a pour prototype :

1. struct file_operations

2. {

3. struct module *owner;

4. loff_t (*llseek) (struct file *, loff_t, int);

5. ssize_t (*read) (struct file *, char __user *,

6. size_t, loff_t *);

7. ssize_t (*write) (struct file *, const char __user *,

8. size_t, loff_t *);

9. ssize_t (*aio_read) (struct kiocb *, const struct iovec *,

10. unsigned long, loff_t);

11. ssize_t (*aio_write) (struct kiocb *, const struct iovec *,

12. unsigned long, loff_t);

13. int (*iterate) (struct file *, struct dir_context *);

14. unsigned int (*poll) (struct file *, struct poll_table_struct *);

15. long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);

16. long (*compat_ioctl) (struct file *, unsigned int, unsigned long);

17. int (*mmap) (struct file *, struct vm_area_struct *);

18. int (*open) (struct inode *, struct file *);

19. int (*flush) (struct file *, fl_owner_t id);

20. int (*release) (struct inode *, struct file *);

21. int (*fsync) (struct file *, loff_t, loff_t, int datasync);

22. int (*aio_fsync) (struct kiocb *, int datasync);

23. int (*fasync) (int, struct file *, int);

24. int (*lock) (struct file *, int, struct file_lock *);

25. ssize_t (*sendpage) (struct file *, struct page *, int, size_t,

26. loff_t *, int);

27. unsigned long (*get_unmapped_area)(struct file *, unsigned long,

28. unsigned long, unsigned long, unsigned long);

29. int (*check_flags)(int);

30. int (*flock) (struct file *, int, struct file_lock *);

31. ssize_t (*splice_write)(struct pipe_inode_info *, struct file *,

32. loff_t *, size_t, unsigned int);

33. ssize_t (*splice_read)(struct file *, loff_t *,

34. struct pipe_inode_info *, size_t, unsigned int);

35. int (*setlease)(struct file *, long, struct file_lock **);

36. long (*fallocate)(struct file *file, int mode, loff_t offset,off_t len);

37. int (*show_fdinfo)(struct seq_file *m, struct file *f);

38. };

Comme vous voyez, elle contient des pointeurs vers diverses fonctions et c'est en définissant ces fonctions qu'on va lier une action du programme client au driver chargé dans le noyau. Vous avez sûrement remarqué que le prototype ne donne seulement le type des paramètres (c'est spécifique des prototypes des sources du kernel).

Nous allons nous intéresser aux fonctions et à leurs paramètres:

1. open().

2. release() Équivalent a close().

3. read()

4. write().

Remarquez que la fonction unlock_ioctl correspond à la fonction ioctl .

La fonction compat_ioctl permet la prise en charge sur un système 64 bits la compatibilité d'un processus 32 bits grâce au transtypage du 3ᵉ argument de qui est de type :

unsigned long sur un système 32 bits.

void * sur un système 64 bits.

IV-B - Description de la fonction open()

Déclaration :

1. static int *open(struct inode *device_file, struct file * instance) ;

La structure inode représente le périphérique que nous souhaitons contrôler. Elle est définie dans <linux/fs.h>.

On peut s'en servir pour vérifier :

1. les droits d'accès,

2. le propriétaire,

3. le numéro majeur et mineur du périphérique,

et bien d'autres choses (consultez les membres dans les sources). La structure file représente l'instance du driver et est définie dans <linux/fs.h>. On peut s'en servir pour :

1. vérifier les droits d'accès (utile dans d'autres fonctions ou il n'y a pas de structure inode passer en argument),

2. vérifier le mode d'accès (O_NONBLOCK),

et bien d'autres choses (consultez les membres dans les sources). Cette fonction doit retourner 0 en cas de succès sinon un code d'erreur. Cette fonction est appelée dans le driver à chaque ouverture par une application du périphérique que nous souhaitons contrôler.

IV-C - Description de la fonction release()

Déclaration :

1. static int *release(struct inode *, struct file *);

Les paramètres sont les mêmes que pour la fonction open() ;

Cette fonction doit retourner 0 en cas de succès sinon un code d'erreur. Cette fonction est appelée à chaque fermeture par une application du périphérique que nous souhaitons contrôler.

IV-D - Description de la fonction read()

Déclaration :

1. static size_t *read(struct file *instance, char __user  *userbuffer,

2. size_t count, loff_t *offset) ;

Cette fonction est appelée dans le driver à chaque opération de lecture fait par l'application qui communique avec le périphérique que nous souhaitons contrôler.

- La structure file joue le même rôle que dans la fonction open().

- Le paramètre userbuffer:

Notez au passage le mot-clé __user devant le paramètre userbuffer signifie que l'adresse pointée se trouve dans l'espace utilisateur (user-space), pointé sur cette adresse. Ceci est l'argument le plus important, car comme énoncé précédemment l'espace mémoire utilisateur (celui de l'application cliente du périphérique que nous souhaitons contrôler) est séparée de l'espace mémoire du noyau (dans lequel s'exécute le driver). Il faut faire une translation d'adresse entre les deux afin de copier - dans l'espace utilisateur - les bytes (que l'application qui communique avec notre périphérique) demandent à lire, et renvoyer le nombre de bytes copiés dans celui-ci.

Pour cela il existe plusieurs fonctions fournies par les sources du noyau définies dans <asm/uaccess.h> qui possèdent un fichier propre à chaque architecture.

copy_to_user(void *dst, const void *src, unsigned long count) ;

copie count bytes depuis *src dans l'espace d'adresse utilisateur *dst et renvoie le nombre de bytes non-copiés.

ou la macro qui ne supporte que des adresses de type char* ou int* :

put_user(const void *to_copy, void *dst) ;

qui renvoie 0 en cas de succès, sinon -EFAULT.

(Remarquer la conversion en nombre négatif du code d'erreur typique de la programmation driver du noyau).

Par exemple pour renvoyer un « Hello world » à l'application qui tente de lire notre périphérique :

copy_to_user(userbuffer, »Hello world »,strlen(Hello world)+1) ;

ou

put_user("Hello world",userbuffer) ;

Ces fonctions font une vérification de la validité des adresses ce que l'on peut empêcher (pour des questions de performance) en employant les fonctions sous-jacentes de ces fonctions qui ne vérifie pas la validité des adresses :

__copy_to_user() ;

__put_user() ;

Finalement on peut vérifier la validité d'une adresse avec la macro :

access_ok(type, addr, size) ;

type : Type of d'access: VERIFY_READ ou VERIFY_WRITE.

addr : adresse à vérifier.

Size : nombre de bytes à vérifier.

- L'argument count correspond au nombre de bytes demandés par l'application communiquant avec notre périphérique - à lire depuis le périphérique.

- L'argument offset est la position dans l'argument userbuffer à partir duquel l'application communiquant avec notre périphérique souhaite lire.

- La fonction doit renvoyer le nombre de bytes copiés dans l'espace utilisateur de l'application communiquant avec notre périphérique.

IV-E - Description de la fonction write()

Déclaration :

1. ssize_t *write(struct file *instance, const char __user *userbuffer,

2. size_t count, loff_t *offset) ;

Cette fonction est appelée dans le driver pour une opération d'écriture (faîtes par l'application communiquant avec le périphérique que nous souhaitons contrôler.

- La structure file joue le même rôle que dans la fonction open().

- Le pointeur userbuffer pointe sur l'adresse où sont stockées les données que le client désire communiquer au périphérique.

Il faut faire une translation d'adresse entre les deux, afin de copier depuis l'espace utilisateur les bytes que l'application communiquant avec notre périphérique demande à écrire - et renvoyer le nombre de bytes copiés dans celui-ci.

Pour cela il existe plusieurs fonctions fournies par les sources du noyau définies dans <asm/uaccess.h> qui possèdent un fichier propre à chaque architecture.

copy_from_user(void *src, const void __user *dst, unsigned long count);

copie count bytes depuis *src dans l'espace d'adresse utilisateur *dst et renvoie le nombre de bytes non-copiés.

ou la macro qui ne supporte que des adresses de type char* ou int* :

get_user(void *dst,const void *to_copy) ;

qui renvoie 0 en cas de succès, sinon -EFAULT.

ou la fonction qui ne supporte que du texte ASCII :

strncpy_user(char *dst,const char __user *src,long count) ;

À copier seulement depuis l'espace utilisateur dans l'espace du noyau avec la fonction :

strnlen_user(const char __user *src,long count) ;

Renvoie la taille du string pointé par src jusqu'au '0' final. Sinon 0 en cas d'erreur (adresse invalide, pas droit d'accès aux données).

Il existe des fonctions sous-jacentes qui ne vérifient pas la validité des adresses.

__copy_from_user() ;

__get_user() ;

- L'argument count correspond au nombre de bytes écrit par l'application communiquant avec notre périphérique.

- L'argument offsetuserbuffer est la position dans l'argument userbuffer à partir duquel l'application communiquant avec notre périphérique désire écrire des données.

- La fonction doit renvoyer le nombre de bytes copiés dans l'espace du noyau.

IV-F - Un exemple Hello world

Voici un exemple, qui renvoie « Hello World » à chaque tentative de lecture en écrivant ce que l'application communiquant avec notre périphérique lui envoie dans le fichier de log.

Le code créant le périphérique et driver de celui-ci : hello_world_driver.c

1. #include <linux/module.h>  /** MODULE_LICENSE &&

2. MODULE_DESCRIPTION &&

3. MODULE_AUTHOR               */

5. #include <linux/cdev.h>    /** cdev_del() &&

6. cdev_add() &&

7. cdev_alloc()                */

9. #include <linux/device.h>  /** class_create() &&

10. device_create()  &&

11. device_destroy()            */

12. #include <linux/fs.h>      /** alloc_chrdev_region() &&

13. unregister_chrdev_region()  */

15. #include <linux/string.h>  /** strlen()                    */

16. #include <linux/fs.h>      /** struct file_operations      */

18. #include <asm/uaccess.h>   /** copy_to_user() &&

19. copy_from_user()            */

21. MODULE_LICENSE("GPL") ;

22. MODULE_DESCRIPTION("Hello World device driver") ;

23. MODULE_AUTHOR("None") ;

25. #define DEVICE_NAME "devname"

27. static dev_t dev_num ;

28. static struct cdev *driver_object ;

29. static struct class *device_class ;

31. static char hello_msg[]="hello world" ;

33. static ssize_t

34. file_ops_read(struct file *instance,char __user *read_buffer,

35. size_t count,loff_t *offset )

36. {

37. ssize_t to_copy, not_copy ;

38. to_copy=min(count,strlen(hello_msg)+1) ;

39. not_copy=copy_to_user(read_buffer,hello_msg,to_copy) ;

40. printk(KERN_DEBUG "%s send to application !!!\n",hello_msg) ;

41. if (not_copy)

42. {

43. printk(KERN_DEBUG "copy_to_user() error !!!\n") ;

44. }

45. return to_copy - not_copy ;

46. }

47. static ssize_t

48. file_ops_write(struct file *instance,const char __user *write_buffer,

49. size_t count,loff_t *offset )

50. {

51. ssize_t to_copy, not_copy ;

52. char kernel_buf[128] ;

53. memset(kernel_buf,'\0',128) ;

54. to_copy=min(count,strlen(write_buffer)+1) ;

55. not_copy=copy_from_user(kernel_buf,write_buffer,to_copy) ;

56. printk(KERN_ALERT "Application send: %s !!!\n",kernel_buf) ;

57. return to_copy-not_copy;

58. }

60. static int

61. file_ops_open(struct inode *device_file,struct file *instance )

62. {

63. printk(KERN_DEBUG "device open function triggering !!!\n") ;

64. printk(KERN_DEBUG "driver major: %d minor %d !!!\n",

65. imajor(device_file),iminor(device_file)) ;

66. if (instance->f_flags & O_RDWR)

67. {

68. printk(KERN_DEBUG "device open in rw mode !!!\n") ;

69. }

70. else if (instance->f_flags & O_RDONLY)

71. {

72. printk(KERN_DEBUG "error: device open in read-only mode !!!\n") ;

73. return -EIO ;

74. }

75. else if (instance->f_flags & O_WRONLY)

76. {

77. printk(KERN_DEBUG "error: device open in read-only mode !!!\n") ;

78. return -EIO ;

79. }

80. return 0 ;

81. }

83. static int

84. file_ops_release(struct inode *device_file,struct file *instance )

85. {

86. printk(KERN_DEBUG "device release function triggering !!!\n") ;

87. return 0 ;

88. }

90. /** Define file_operations structure

91. to bind to driver for client actions

92. processing.                   */

94. struct file_operations fops =

95. {

96. .read         = file_ops_read  ,

97. .write        = file_ops_write ,

98. .open         = file_ops_open  ,

99. .release      = file_ops_release  ,

100. } ;

102. static int __init my_device_init(void)

103. {

104. static int minor=0 ;

105. static int minor_numbers=1 ;

106. printk(KERN_DEBUG "start device creating\n") ;

107. if (alloc_chrdev_region(&dev_num,minor,minor_numbers,DEVICE_NAME) < 0)

108. {

109. /** Allocate space for device and major number dev_num

110. with minor number minor and minor_numbers count

111. and as device name devname                          */

113. printk(KERN_DEBUG "Device number and space alloctating error !!! \n") ;

114. return -EIO ;

115. }

116. driver_object=cdev_alloc() ;

117. /** Driver space allocating and instantiation as struct cdev object. */

119. if (driver_object == NULL)

120. {

121. goto free_device_number ;

122. }

123. driver_object->owner=THIS_MODULE ;

124. driver_object->ops=&fops ;

126. if (cdev_add(driver_object,dev_num,1))

127. {

128. /** register the driver object to the kernel  */

129. goto free_device ;

130. }

131. device_class=class_create(THIS_MODULE,DEVICE_NAME) ;

132. /** create new device class     */

134. device_create(device_class,NULL,dev_num,NULL,"%s",DEVICE_NAME) ;

135. /** register device in /dev/  filesystem  */

137. if (device_class == NULL)

138. {

139. printk(KERN_DEBUG "Device class creating error !!!\n") ;

140. goto free_device ;

141. }

142. printk(KERN_DEBUG "Device successfull created !!!\n") ;

143. return 0 ;

145. /* Errors handlong gotos */

146. free_device :

147. printk(KERN_DEBUG "Must free allocated space for device.\n") ;

148. kobject_put(&driver_object->kobj) ;

149. free_device_number :

150. printk(KERN_DEBUG "chrdev registering error !!!\n") ;

151. unregister_chrdev_region(dev_num,1) ;

152. return -EIO ;

153. }

154. static void

155. __exit my_device_exit(void)

156. {

157. device_destroy(device_class,dev_num) ;

158. /** destroy device */

160. class_destroy(device_class) ;

161. /** destroy device class */

163. cdev_del(driver_object) ;

164. /** free driver_object memory space */

166. unregister_chrdev_region(dev_num,1) ;

167. /** unregister dev_t dev_num and minors count 1 */

169. printk(KERN_DEBUG "Driver destruction succesfull !!!\n") ;

170. return ;

171. }

173. module_init(my_device_init) ;

174. module_exit(my_device_exit) ;

Et voici le code de l'application client de notre driver : hello_world_client.c

1. #include <stdio.h>

2. #include <string.h>

3. #include <stdlib.h>

4. #include <fcntl.h>

5. #include <unistd.h>

6. #include <sys/types.h>

7. #include <sys/stat.h>

9. int main(void)

10. {

11. int fd ;

12. if ((fd=open("/dev/devname",O_RDWR | O_NOCTTY ) ) >= 0)

13. {

14. /** Device opening succesfull */

15. fprintf(stdout,"open devname succesfull !!!\n") ;

16. }

17. else

18. {

19. fprintf(stderr,"open err) %m\n") ;

20. exit(EXIT_FAILURE) ;

21. }

23. int ctrl=1 ;

24. while (ctrl)

25. {

26. char *rd_buf=calloc(128,sizeof(char)) ;

27. char *wr_buf=calloc(128,sizeof(char)) ;

29. if (read(fd,rd_buf,(size_t) 128) > 0)

30. {

31. /** Reading from device succcessfull */

32. fprintf(stdout,"device devname answer: %s\n",rd_buf) ;

33. }

34. else

35. {

36. fprintf(stderr,"rd err) %m\n") ;

37. exit(EXIT_FAILURE) ;

38. }

40. fprintf(stdout,"Enter message to send to device\n") ;

42. fgets(wr_buf,128,stdin) ;

44. wr_buf[strlen(wr_buf)-1]='\0' ;

45. /** Disable the linefeed character added from fgets() */

47. if (strcmp(wr_buf,"stop") == 0)

48. {

49. /** We stop the commnunication with the device */

50. ctrl=0 ;

51. break ;

52. }

54. if (write(fd,wr_buf,strlen(wr_buf)) > 0)

55. {

56. /** Message sending to device succcessfull */

57. fprintf(stdout,"message send to device:\n%s\n",wr_buf) ;

58. }

61. else

62. {

63. fprintf(stderr,"wr err) %m\n") ;

64. exit(EXIT_FAILURE) ;

65. }

67. free(rd_buf) ;

68. free(wr_buf) ;

69. }

70. close(fd) ;

71. exit(EXIT_SUCCESS) ;

72. }

Après avoir exécuté le fichier Makefile correspondant au fichier hello_world_driver.c et après compilation de l'application client du driver hello_world_client.c . Vous pourrez les faire communiquer ainsi :

1. $ sudo make

2. $ sudo insmod hello_world_driver.ko

3. $ gcc hello_world_client.c -o device_client

4. $ sudo device_client # Sinon changer les droits d'accès de /dev/devname

5. open devname succesfull !!!

6. device devname answer: hello world

7. Enter message to send to device

8. hi you device

9. message send to device:

10. hi you device

11. device devname answer: hello world

12. Enter message to send to device

13. stop

14. $

15. $ dmesg

16. [ 6784.816991] start device creating

17. [ 6784.817151] Device successfull created !!!

18. [ 6805.066774] device open function triggering !!!

19. [ 6805.066779] driver major: 250 minor 0 !!!

20. [ 6805.066781] device open in rw mode !!!

21. [ 6805.066866] hello world send to application !!!

22. [ 6815.855711] Application send: hi you device !!!

23. [ 6815.855743] hello world send to application !!!

24. [ 6818.785004] device release function triggering !!!

V - Un exemple de driver de périphérique virtuel

V-A - Introduction à l'exemple avancé

Nous allons écrire un driver pour un périphérique virtuel avec quelques notions de programmation noyau en plus.

Nous allons nous servir du type de données atomique : atomic_t

- Pour gérer le nombre d'application se connectant au périphérique. Nous souhaitons qu'une seule application puisse se connecter.

- Pour le buffer de lecture et d'écriture.

Pour initialiser une variable de type atomic_t statiquement nous allons utiliser la macro :

ATOMIC_INIT() définie dans <asm/atomic.h> qui initialise une variable de type atomic_t avec l'argument passé en paramètre.

1. static atomic_t access_counter = ATOMIC_INIT(-1) ;

2. /** atomic access counter declaration and initialisation. */

4. static atomic_t bytes_read_available = ATOMIC_INIT(-1) ;

5. /** atomic bytes to read checker variable declaration and initialisation.  */

7. static atomic_t bytes_write_available = ATOMIC_INIT(-1) ;

8. /** atomic bytes to write checker variable declaration and initialisation. */

9. Puis nous allons définir deux macros qui vérifient respectivement si les données sont disponibles en lecture et en écriture :

10. #define RD_OK ( atomic_read(&bytes_read_available) != 0)

11. /** Macro to check if data available to be read.  */

13. #define WR_OK ( atomic_read(&bytes_write_available) != 0)

14. /** Macro to check if data available to be written.  */

Nous allons aussi nous occuper de l'aspect de la disponibilité de données en faisant dormir le périphérique - en attendant que les données soit effectivement disponibles et en implémentant un type de données prenant la forme d'une queue. De type wait_queue_head_t définis dans <linux/wait.h>.

Une queue est une structure de données fournis par le noyau, fonctionnant selon le principe que l'on peut écrire et lire des données dans/depuis celle-ci sous forme d'accès FIFO (First In First Out).

Mais ce type de données est une wait_queue_head_t signifiant que l'accès à la queue est soumis à une mise en attente souhaitant qu'un événement se produise. Nous allons utiliser la fonction : wait_event_interruptible(wait_queue_head_t queue,condition) ; définie dans <linux/wait.h>.

Tout cela endort notre périphérique - en attendant un signal - quand il arrive, le signal produit la vérification de la condition (celle-ci décide si le périphérique continue à dormir ou pas).

Afin de générer des nombres aléatoires de calculs, nous allons faire une sorte de process list (commande ps) que nous enregistrerons dans une structure - dont les membres nous donnent matière à générer deux nombres aléatoires - nous prendrons qu'un seul élément (l'index nous est fourni par le nombre des changements de contexte du processus actuellement en cours d'exécution, accessible par la macro current) :

- Le temps imparti au processus pour s'exécuter dans le processeur (celui-ci est calculé par ordonnanceur).

- Le temps passé dans le processeur depuis son lancement.

V-B - Code d'un driver de périphérique virtuel

Voici un exemple, demande à faire une addition à la première tentative de lecture puis enregistre votre réponse envoyée par la fonction write de l'application communicante avec notre périphérique et vous dit à la deuxième tentative de lecture si le résultat est exact en alternance.

Le code créant le périphérique et driver de celui-ci: calc_device_driver.c

1. #include <linux/module.h>  /** MODULE_LICENSE &&

2. MODULE_DESCRIPTION &&

3. MODULE_AUTHOR               */

5. #include <linux/cdev.h>    /** cdev_del() &&

6. cdev_add() &&

7. cdev_alloc()               */

9. #include <linux/device.h>  /** class_create() &&

10. device_create()  &&

11. device_destroy()           */

13. #include <linux/fs.h>      /** alloc_chrdev_region() &&

14. unregister_chrdev_region() */

16. #include <linux/string.h>  /** strncpy()                  */

18. #include <linux/fs.h>      /** struct file_operations     */

20. #include <asm/uaccess.h>   /** copy_to_user() &&

21. copy_from_user             */

23. #include <linux/sched.h>   /** struct task_struct         */

25. MODULE_LICENSE("GPL") ;

26. MODULE_DESCRIPTION("Addition device driver") ;

27. MODULE_AUTHOR("None") ;

29. #define DEVICE_NAME "devname"

31. static dev_t dev_num ;

32. static struct cdev *device_object ;

33. static struct class *device_class ;

35. static wait_queue_head_t wait_read, wait_write ;

37. static atomic_t access_counter = ATOMIC_INIT(-1) ;

38. /** atomic access counter. */

40. static atomic_t bytes_read_available = ATOMIC_INIT(-1) ;

41. /** atomic bytes to read checker variable initialisation.  */

43. static atomic_t bytes_write_available = ATOMIC_INIT(-1) ;

44. /** atomic bytes to write checker variable initialisation. */

48. #define RD_OK ( atomic_read(&bytes_read_available) != 0)

49. /** Macro to check if data available to be read.           */

51. #define WR_OK ( atomic_read(&bytes_write_available) != 0)

52. /** Macro to check if data available to be written.        */

55. unsigned long result ; /** Addition result */

57. char res_str[128] ;

58. /** char buffer for getting answers from client application */

60. int status=0 ;

61. /** Switcher:

62. *  Sending adddition.

63. *  Sending result check.

64. ************************/

66. struct Data_Random

67. {

68. /** Data structure for process list */

69. unsigned long value1 ;

70. unsigned long value2 ;

71. }

72. random[256] ;

74. u16 c ;

75. unsigned long value1 ; /** Operand 1  */

76. unsigned long value2 ; /** Operand 2  */

78. void register_random_data(void)

79. {

81. struct task_struct *task ; /** Iterator */

83. c=0 ;

85. for_each_process(task)

86. {

87. /** Registering 256 processes in run. */

89. random[c].value1=task->se.vruntime ;

90. /** The amount of time given for the process to stay in the      processor. */

92. random[c].value2=task->se.exec_start ;

93. /** The time the process spend in the processor since start.           */

94. c++ ;

96. if (c == 256)

97. {

98. break ;

99. }

101. }

102. return ;

103. }

107. void set_random_data(void)

108. {

109. struct task_struct *task ;

111. task=current ; /** Get current process */

113. value1=random[(task->fpu_counter < c) ? task->fpu_counter : 0 ].value1 % 255 ;

114. /** task->fpu_counter The number of consecutive

115. context switches that the FPU is used.   */

117. value2=random[(task->fpu_counter < c) ? task->fpu_counter : 0 ].value2 % 255 ;

118. /** task->fpu_counter The number of consecutive

119. context switches that the FPU is used.   */

121. return ;

123. }

125. static int

126. file_ops_open(struct inode *device_file,struct file *instance )

127. {

129. if (instance->f_flags & O_RDWR)

130. {

131. printk(KERN_ALERT "device open in rw mode !!!\n") ;

133. if (atomic_inc_and_test(&access_counter) == 1)

134. {

135. /** We permit only one client application at the same time

136. *  by testing atomic_inc_and_test(&access_counter)

137. *  who return 1 only if access_counter == 1 after incrementing

138. ***************************************************************/

139. return 0 ;

140. }

141. else

142. {

143. return -EBUSY ;

144. }

145. }

146. else

147. {

148. printk(KERN_ALERT "device open in wrong mode !!!\n") ;

149. return -EIO ;

151. }

153. printk(KERN_DEBUG "device open function triggering !!!\n") ;

154. return 0 ;

155. }

159. static int

160. file_ops_release(struct inode *device_file,struct file *instance )

161. {

162. atomic_dec(&access_counter) ;

163. /** Release access control lock */

165. printk(KERN_DEBUG "device release function triggering !!!\n") ;

166. return 0 ;

167. }

170. static ssize_t

171. file_ops_read(struct file *instance,char __user *read_buffer,

172. size_t count,loff_t *offset )

173. {

175. size_t to_copy, not_copy ;

176. char buffer_kern_space[128] ; /** kernel data-space buffer */

178. if ((instance->f_flags & O_NONBLOCK) && ! RD_OK)

179. {

180. /** case O_NONBLOCK modus and data to read not available. */

181. printk(KERN_DEBUG "device read non-block and not ready !!!\n") ;

182. return -EAGAIN ;

183. }

185. if (wait_event_interruptible(wait_read,RD_OK))

186. {

187. /** Wait until data available throught RD_OK macro check.  */

188. printk(KERN_DEBUG "device read not wake up error !!!\n") ;

189. return -ERESTART ;

190. }

192. to_copy=min((size_t) atomic_read(&bytes_read_available),count) ;

193. /** atomic read operation and return gthe number of bytes available. */

195. if (status == 0)

196. {

197. register_random_data() ;

198. set_random_data() ;

200. result = value1 + value2 ;

202. sprintf(buffer_kern_space,"\nHello compute:\n %lu + %lu",value1,value2) ;

203. /** copy readed data in kernel buffer to answers */

204. status=1 ;

205. }

206. else

207. {

208. if (result == simple_strtoul(res_str,NULL,0))

209. {

210. sprintf(buffer_kern_space,"RIGHT\n") ;

211. /** Wrinting answers in kernel buffer to send to client. */

212. }

213. else

214. {

215. sprintf(buffer_kern_space,"WRONG\n") ;

216. /** Wrinting answers in kernel buffer to send to client. */

217. }

218. status=0 ;

219. }

221. not_copy=copy_to_user(read_buffer,buffer_kern_space,to_copy) ;

222. /** copy readed data in kernel-space buffer to return to client application.

223. * and return number of not read data

224. **************************************************************************/

226. atomic_sub(to_copy-not_copy,&bytes_read_available) ;

227. /** atomic data to read computing */

229. return to_copy - not_copy ;

231. }

232. static ssize_t

233. file_ops_write(struct file *instance,const char __user *write_buffer,

234. size_t count,loff_t *offset ) {

236. size_t to_copy, not_copy ;

238. printk(KERN_DEBUG "device write function triggering !!!\n") ;

240. if ((instance->f_flags & O_NONBLOCK) && ! WR_OK)

241. {

242. /** case O_NONBLOCK modus and data to write not available. */

243. printk(KERN_DEBUG "device write non-block and not ready !!!\n") ;

244. return -EAGAIN ;

245. }

247. if (wait_event_interruptible(wait_write,WR_OK))

248. {

249. /** Wait until data available throught WR_OK macro check.  */

250. printk(KERN_DEBUG "device write not wake up error !!!\n") ;

251. return -ERESTART ;

252. }

254. memset(res_str,'\0',128) ;

256. to_copy=min((size_t) atomic_read(&bytes_write_available),count) ;

257. /** atomic read operation and return adress from end of read data. */

259. not_copy=copy_from_user(res_str,write_buffer,to_copy) ;

261. atomic_sub(to_copy-not_copy,&bytes_write_available) ;

262. /** atomic data to read computing */

265. return to_copy - not_copy ;

267. }

271. struct file_operations fops =

272. {

273. .read         = file_ops_read  ,

274. .write        = file_ops_write ,

275. .open         = file_ops_open  ,

276. .release      = file_ops_release  ,

278. } ;

281. static int __init my_device_init(void)

282. {

283. static int minor=0 ;

284. static int minor_numbers=1 ;

286. printk(KERN_DEBUG "start device creating !!!\n") ;

288. if (alloc_chrdev_region(&dev_num,minor,minor_numbers,DEVICE_NAME) < 0)

289. {

290. /** allocate space for device dev_t dev_num with

291. minor number minor and minor_numbers count

292. as device name DEVICE_NAME */

294. printk(KERN_DEBUG "chrdev alloc error !!! \n") ;

295. return -EIO ;

296. }

298. device_object=cdev_alloc() ;

299. /** device instantiation with space allocation as struct cdev. */

301. if (device_object == NULL)

302. {

303. goto free_device_number ;

304. }

306. device_object->ops=&fops ;

307. device_object->owner=THIS_MODULE ;

309. if (cdev_add(device_object,dev_num,1))

310. {

311. /** register the device object to the kernel with

312. the device number dev_num and

313. counts of minor numbers 1 */

315. goto free_device ;

316. }

318. device_class=class_create(THIS_MODULE,DEVICE_NAME) ;

319. /** create new device class */

320. device_create(device_class,NULL,dev_num,NULL,"%s",DEVICE_NAME) ;

321. /** register device in /dev/  filesystem */

323. if (device_class == NULL)

324. {

325. printk(KERN_DEBUG "device class creating error !!!\n") ;

326. return -1 ;

327. }

329. printk(KERN_DEBUG "device successfull created !!!\n") ;

330. return 0 ;

332. /** error handling goto ; */

333. free_device :

334. printk(KERN_DEBUG "kobject triggering\n") ;

335. kobject_put(&device_object->kobj) ;

336. free_device_number :

337. printk(KERN_DEBUG "chrdev registering error !!!\n") ;

338. unregister_chrdev_region(dev_num,1) ;

339. return -EIO ;

340. }

342. static void __exit my_device_exit(void)

343. {

344. device_destroy(device_class,dev_num) ;

345. /** destroy device */

346. class_destroy(device_class) ;

347. /** destroy device class */

349. cdev_del(device_object) ;

350. /** free device_object memory space */

351. unregister_chrdev_region(dev_num,1) ;

352. /** unregister dev_t dev_num and minors count 1 */

354. printk(KERN_DEBUG "driver destruction succesfull !!!\n") ;

355. return ;

357. }

359. module_init(my_device_init) ;

360. module_exit(my_device_exit) ;

Et voici le code de l'application client de notre driver : calc_device_client.c

1. #include <stdio.h>

2. #include <string.h>

3. #include <stdlib.h>

4. #include <fcntl.h>

5. #include <unistd.h>

6. #include <sys/types.h>

7. #include <sys/stat.h>

9. int main(void)

10. {

11. int fd ;

12. if ((fd=open("/dev/devname",O_RDWR| O_NOCTTY ) ) >= 0)

13. {

14. fprintf(stdout,"open devname succesfull !!!\n") ;

15. }

16. else

17. {

18. fprintf(stderr,"1) %m\n") ;

19. exit(EXIT_FAILURE) ;

20. }

23. int c=0 ;

24. while (c < 5)

25. {

26. char *rd_buf=malloc(128) ;

27. if (read(fd,rd_buf,(size_t) 128) > 0)

28. {

29. fprintf(stdout,"\ndevname send:\n%s\n",rd_buf) ;

30. }

31. else

32. {

33. fprintf(stderr,"2) %m\n") ;

34. exit(EXIT_FAILURE) ;

35. }

36. free(rd_buf) ;

38. fprintf(stdout,"\nEnter answer to send to driver\n>>> ") ;

39. char *write_buf=malloc(128) ;

41. fgets(write_buf,128,stdin) ;

42. write_buf[strlen(write_buf)-1]='\0' ;

44. if (write(fd,write_buf,strlen(write_buf)) > 0)

45. {

46. fprintf(stdout,"\nsend answer: [ \"%s\" ] to devname\n",write_buf) ;

47. }

48. else

49. {

50. fprintf(stderr,"3) %m\n") ;

51. exit(EXIT_FAILURE) ;

52. }

53. free(write_buf) ;

54. char *response=malloc(128) ;

55. if (read(fd,response,(size_t) 128) > 0)

56. {

57. fprintf(stdout,"\ndevname answer:\n%s\n",response) ;

58. }

59. else

60. {

61. fprintf(stderr,"2) %m\n") ;

62. exit(EXIT_FAILURE) ;

63. }

64. free(response) ;

65. c++ ;

66. sleep(1) ;

68. }

69. close(fd) ;

71. exit(EXIT_SUCCESS) ;

73. }

Voila vous n'avez qu'à exécuter le fichier Makefile, à insérer le module dans le noyau avec la commande insmod et à compiler et lancer le client…