Salut,
Je suis en train de développer un module noyau qui utilise le système de fichier virtuel /proc.
Je me demandais s'il était possible d'attacher un call back sur un dossier de ce système de fichier.
Le noyau utilise la même structure (proc_dir_entry) pour un fichier et un dossier. Je vais essayer d'attacher une fonction call back sur un des deux pointeurs (read_proc ou write_proc) de la structure de mon dossier mais je ne sais pas si il faut utiliser le même prototypage que pour un fichier.
Je vous pose donc la question pour savoir si je fonce dans le mur.
Merci.
# bon j'avoue
Posté par TheBreton . Évalué à 1.
Mais sous unix tout est fichier donc a priori c'est dans l'esprit effectivement.
Maintenant ce que je ne comprend pas c' est pourquoi tu n'utiliserais pas la fops de ton module dans /dev ? Car /proc est plutot dans l'information module->user que dans l'interaction module<->user
[^] # Re: bon j'avoue
Posté par Doude . Évalué à 1.
J'aimerais pouvoir intercepter la création d'un fichier ou bien lister et lire ces fichiers dans ce dossier depuis le noyau.
Je ne saisie pas 'intérêt de pouvoir créer des fichiers dans le procfs depuis l'espace utilisateur s'il n'est pas possible de le remonter au noyau. Pour toi le procfs ne sert qu'à faire transiter des info depuis le noyau vers l'espace utilisateur ?
PS : que signifie fops ?
[^] # about fops
Posté par s[e]th & h[o]lth (site web personnel) . Évalué à 1.
Par exemple :
fops = {
read : my_read_function,
write : my_write_function,
open : my_open_function,
release : my_release_function /* correspond a close */
};
[^] # Re: bon j'avoue
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: bon j'avoue
Posté par TheBreton . Évalué à 1.
http://lwn.net/Kernel/LDD3/
tu trouveras toutes les reponses a tes question (y compris sur le passage d'argument au module au moment du chargement qui serait bien plus souple que le define a la compilation).
Pour le fops et le role de /proc dans le systeme les explications si dessous sont suffisantes.
Bonne lecture
# Fs dédié
Posté par peck (site web personnel) . Évalué à 2.
# ben en fait non
Posté par niclone (site web personnel) . Évalué à 2.
Donc tu peux, via inotify détecter des processus userland qui vont aller voir dans /proc, mais tu ne recevra aucun callback pour par exemple la création d'un nouveau répertoire /proc/$pid associé à un nouveau processus, vu que ce répertoire n'est pas réellement créé.
Hint: Tu peux tester ce genre de choses avec la commande inotifywait dans un terminal.
# Autre question pour mle Makefile
Posté par Doude . Évalué à 1.
Comment je peux passer des options à la compilation du module, comme une option de debug ?
Voila le makefile que j'utilise :
obj-m += my_driver.o
my_driver-objs := mydriver1.o mydriver2.o
all:
$(MAKE) -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
$(MAKE) -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
J'aimerai passer une option qui active le debug et une qui donne le niveau de "verbose" (entre 0 et 3).
[^] # Re: Autre question pour mle Makefile
Posté par Doude . Évalué à 2.
EXTRA_CFLAGS += -DCONFIG_DRIVER_DEBUG -DCONFIG_DRIVER_DEBUG_VERBOSE=3
Ça correspond à un #define dans le code.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.