Bonjour,
Je suis en train de développé un driver et une librairie associée.
Je cherche le moyen de transmettre une sorte d'interruption software ou un signal depuis le driver vers l'application afin de lui indiquer que d enouvelles données sont prètes.
Quel est la façon standard de faire ce genre de chose ?
Merci kpa
# Quelques solutions
Posté par Damien Lespiau (site web personnel) . Évalué à 4.
- Le plus simple : un driver en mode caractère par exemple accessible par /dev/myeventmanager qui bloque sur un read(). Lorsque ton driver a besoin de signaler un event, il va utiliser le driver derrière /dev/myeventmanager pour débloquer le read et passer une structure du type
struct myevent {
u32 type;
union {
u32 arg_type1;
u16 arg_type2;
};
};
au processus qui vient de se faire débloquer pour lui dire quel event on vient d'émettre. Biens sûr il est possible d'améliorer l'idée :
- rajouter le support de select(), poll(), epoll()
- se faire une API dans le driver associé à /dev/myeventmanager pour que le
reste du noyau puisse envoyer facilement des events.
- ...
- Le "vieux" moyen de faire ça est d'utiliser les signaux UNIX, le driver balance un signal lorsqu'il le souhaite à un processus qui c'est enregistré (par le moyen d'un open() ou d'un ioctl par exemple) au préalable
- On peut essayer d'utiliser une socket netlink.
- On peut tenter de regarder dans les nouveaux syscall pour supporter des events qui viennent du noyau :
- kevent (aujourd'hui mort)
- signalfd()
piiioufff ça en fait des solutions. Reste plus qu'a débroussailler tout ça.
[^] # Re: Quelques solutions
Posté par Bruno Muller . Évalué à 1.
Et pour les détails d'implémentation, voir le chapitre 6 de l'excellent «Linux Device Drivers» : http://lwn.net/Kernel/LDD3/
# hal et dbus
Posté par Émilien Tlapale . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.