{"id":4979,"date":"2017-06-06T04:00:41","date_gmt":"2017-06-06T03:00:41","guid":{"rendered":"https:\/\/www.blaess.fr\/christophe\/?p=4979"},"modified":"2017-06-06T04:49:25","modified_gmt":"2017-06-06T03:49:25","slug":"kernel-interruptions-et-tasklets","status":"publish","type":"post","link":"https:\/\/www.blaess.fr\/christophe\/2017\/06\/06\/kernel-interruptions-et-tasklets\/","title":{"rendered":"[Kernel] Interruptions et tasklets"},"content":{"rendered":"

\"[Kernel<\/a><\/p>\n

Il existe plusieurs m\u00e9canismes propos\u00e9s par le noyau Linux pour programmer un traitement \u00e0 r\u00e9aliser lorsqu’un p\u00e9riph\u00e9rique externe d\u00e9clenche une interruption pour nous notifier de l’occurrence d’un \u00e9v\u00e9nement. Gestionnaire monolithique, tasklet<\/em>, workqueue<\/em>, threaded interrupt<\/em>, chaque solution a des avantages et des inconv\u00e9nients, qu’il est int\u00e9ressant de conna\u00eetre pour optimiser l’efficacit\u00e9 de nos traitements.<\/p>\n

\n\n<\/p>\n

Gestion des interruptions<\/h1>\n

R\u00e9capitulons rapidement le principe des interruptions sous Linux. Il convient tout d’abord de pr\u00e9ciser que du fait de la portabilit\u00e9 du noyau sur un grand nombre d’architectures, les m\u00e9canismes tr\u00e8s bas-niveau sont totalement abstraits pour ce qui concerne la plupart du code kernel classique (dans un driver<\/em> par exemple).<\/p>\n

Lorsqu’un p\u00e9riph\u00e9rique externe – disons un contr\u00f4leur d’entr\u00e9es-sorties GPIO par exemple – d\u00e9sire notifier le processeur de l’occurrence d’une situation int\u00e9ressante (par exemple le changement d’\u00e9tat d’une broche d’entr\u00e9e), il envoie un signal sur une entr\u00e9e du contr\u00f4leur d’interruption<\/strong> APIC<\/strong> (Advanced Programmable Interrupt Controler<\/em>). De nos jours celui-ci est int\u00e9gr\u00e9 directement dans le microprocesseur, mais dans les anciens PC par exemple, il existait sous forme de composant ind\u00e9pendant.<\/p>\n

Le contr\u00f4leur d’interruption effectue une demande d’interruption IRQ<\/strong> (Interrupt Request<\/em>) aupr\u00e8s du processeur principal. Ce dernier arr\u00eate le traitement en cours, sauvegarde son \u00e9tat (ses registres) dans la pile et interroge le contr\u00f4leur d’interruption pour conna\u00eetre l’\u00e9v\u00e9nement survenu. L’APIC lui indique la source du signal initial sous forme d’un num\u00e9ro. Le processeur d\u00e9route alors son ex\u00e9cution sur une routine de traitement<\/strong> bas-niveau charg\u00e9e de prendre en compte l’interruption et de r\u00e9agir en cons\u00e9quence.<\/p>\n

Une fois cette routine de traitement termin\u00e9e le processeur reprend le cours de ses op\u00e9rations pr\u00e9c\u00e9dentes comme si de rien n’\u00e9tait.<\/p>\n

\"fig-01

Fig-01 – D\u00e9clenchement d’une interruption<\/p><\/div>\n

On peut voir les diff\u00e9rentes interruptions g\u00e9r\u00e9es par le noyau Linux dans le pseudo-fichier \/proc\/interrupts<\/code><\/strong>. Par exemple sur un Raspberry Pi 3, on observe les donn\u00e9es suivantes.<\/p>\n

# cat \/proc\/interrupts<\/strong> \n           CPU0       CPU1       CPU2       CPU3       \n 16:          0          0          0          0  bcm2836-timer   0 Edge      arch_timer\n 17:        974        466        348       1505  bcm2836-timer   1 Edge      arch_timer\n 23:         18          0          0          0  ARMCTRL-level   1 Edge      3f00b880.mailbox\n 24:          2          0          0          0  ARMCTRL-level   2 Edge      VCHIQ doorbell\n 39:          1          0          0          0  ARMCTRL-level  41 Edge    \n 46:          0          0          0          0  ARMCTRL-level  48 Edge      bcm2708_fb dma\n 48:        267          0          0          0  ARMCTRL-level  50 Edge      DMA IRQ\n 50:          0          0          0          0  ARMCTRL-level  52 Edge      DMA IRQ\n 62:       8865          0          0          0  ARMCTRL-level  64 Edge      dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1\n 79:          0          0          0          0  ARMCTRL-level  81 Edge      3f200000.gpio:bank0\n 80:          0          0          0          0  ARMCTRL-level  82 Edge      3f200000.gpio:bank1\n 86:          4          0          0          0  ARMCTRL-level  88 Edge      mmc0\n 87:        116          0          0          0  ARMCTRL-level  89 Edge      uart-pl011\n 92:        456          0          0          0  ARMCTRL-level  94 Edge      mmc1\nFIQ:              usb_fiq\nIPI0:          0          0          0          0  CPU wakeup interrupts\nIPI1:          0          0          0          0  Timer broadcast interrupts\nIPI2:        323        610        369        468  Rescheduling interrupts\nIPI3:          2          5          4          4  Function call interrupts\nIPI4:          2          2          0          0  Single function call interrupts\nIPI5:          0          0          0          0  CPU stop interrupts\nIPI6:          1          0          0          0  IRQ work interrupts\nIPI7:          0          0          0          0  completion interrupts\nErr:          0\n#<\/pre>\n
La premi\u00e8re colonne repr\u00e9sente le num\u00e9ro de l’interruption (sauf pour celles du bas de la liste, FIQ et IPIx qui repr\u00e9sentent des interruptions internes au processeur). Les quatre colonnes suivantes indiquent le nombre d’occurrence de chaque interruption depuis le boot<\/em> du syst\u00e8me sur chacun des quatre c\u0153urs de processeur. Les valeurs sont faibles ici, le Raspberry Pi 3 vient de d\u00e9marrer. Les colonnes suivantes affichent le type de contr\u00f4leur, un num\u00e9ro interne \u00e0 celui-ci, et le driver concern\u00e9.<\/p>\n
Les fonctions de traitement bas-niveau sont d\u00e9j\u00e0 \u00e9crites dans le noyau Linux et nous n’avons pas \u00e0 y toucher. Elles ont pour r\u00f4le d’appeler des fonctions de plus haut-niveau que l’on nomme routines de service<\/strong> (Interrupt Service Routine<\/em> ou ISR<\/strong>), et ce sont ces routines de service que nous pouvons \u00e9crire dans nos drivers. Une fonction bas-niveau a \u00e9galement pour r\u00f4le de d\u00e9sactiver dans l’APIC l’interruption qui l’a d\u00e9clench\u00e9e avant d’appeler la routine de service et de r\u00e9activer l’interruption ensuite. Imaginons le d\u00e9clenchement d’une hypoth\u00e9tique interruption 100\u00a0:<\/p>\n
\"Fig-02
Fig-02 – Handlers bas-niveau et ISR<\/p><\/div>\n
Lorsque, dans le reste de cet article je parlerai – avec un l\u00e9ger abus de langage – de gestionnaire (ou de handler<\/em>) d’interruption, il s’agira toujours d’une routine de service invoqu\u00e9e par une fonction de plus bas-niveau. Autrement dit, les sch\u00e9mas \u00e0 venir ne repr\u00e9senteront plus les handlers<\/em> bas-niveau, mais uniquement les routines ISR.<\/p>\n
\"Fig-03
Fig-03 – Handler d’interruption<\/p><\/div>\n
Pr\u00e9cisons d\u00e8s \u00e0 pr\u00e9sent qu’une fonction bas-niveau peut appeler successivement plusieurs routines de service en r\u00e9ponse \u00e0 la m\u00eame interruption. Par exemple dans le fichier \/proc\/interrupts<\/code> ci-dessus, on voit que l’interruption 62 est trait\u00e9e conjointement par trois routines de service appartenant aux drivers dwc_otg<\/code>, dwc_otg_pcd<\/code>, et dwc_otg_hcd<\/code> appel\u00e9es successivement. C’est ce qu’on nomme une interruption partag\u00e9e<\/strong>.<\/p>\n
\"Fig-04
Fig-04 – Interruption partag\u00e9e<\/p><\/div>\n
Il est possible, lors de l’\u00e9criture d’un driver d’agir de diff\u00e9rentes fa\u00e7ons sur le traitement des interruptions.
\nOn peut d\u00e9sactiver (on dit g\u00e9n\u00e9ralement \u00ab\u00a0masquer<\/strong>\u00ab\u00a0) ou activer (\u00ab\u00a0d\u00e9masquer<\/strong>\u00ab\u00a0) le traitement d’une interruption. Si on masque une interruption, et qu’elle se produit effectivement, l’IRQ restera en attente au niveau de l’APIC, jusqu’\u00e0 ce que le processeur d\u00e9masque l’interruption. C’est \u00e0 ce moment seulement qu’il recevra la demande en attente.<\/p>\n
\"Fig-05
Fig-05 – Masquage d’interruption<\/p><\/div>\n
Il faut bien comprendre qu’une seule instance<\/strong> de l’interruption sera d\u00e9livr\u00e9e au moment du d\u00e9blocage, m\u00eame si elle est survenue \u00e0 plusieurs reprises pendant la p\u00e9riode de masquage.<\/p>\n
\"Fig-06
Fig-06 – Occurrences d’interruption masqu\u00e9e<\/p><\/div>\n
Sur certains processeurs, il existe des interruptions non-masquables<\/strong> servant \u00e0 la notification d’\u00e9v\u00e9nements tr\u00e8s urgents.
\nEn outre certaines interruptions peuvent \u00eatre plus prioritaires que d’autres. Du fait de la portabilit\u00e9 de Linux sur de nombreuses architectures, cette notion n’est pas prise en compte au niveau de l’API propos\u00e9e aux drivers.<\/p>\n
Un peu de pratique<\/h1>\n
Nous allons commencer quelques exp\u00e9riences avec les interruptions. J’ai choisi comme plate-forme d’illustration pour cet article le Raspberry Pi 3<\/strong> en raison de sa grande disponibilit\u00e9. Toutefois les exemples sont adaptables sur d’autres cartes. Durant des sessions de formation je les ai test\u00e9s sur de nombreux autres syst\u00e8mes (BeagleBoneBlack, Pandaboard, IGEPv2, i.MX6 Sabrelite, toute la gamme des Raspberry Pi, etc.) en adaptant les num\u00e9ros de GPIO.<\/p>\n
Dans notre premier exemple nous allons installer un petit gestionnaire d’interruption tr\u00e8s simple qui inscrira lors de son d\u00e9clenchement un message dans les traces du noyau. L’int\u00e9r\u00eat de travailler avec un Raspberry Pi est de pouvoir facilement g\u00e9rer communications avec l’ext\u00e9rieur gr\u00e2ce aux GPIO<\/strong>, et de d\u00e9clencher facilement des interruptions avec un simple morceau de fil \u00e9lectrique.<\/p>\n
J’ai fait le choix, pour \u00e9viter de mettre en \u0153uvre un environnement de cross-compilation qui compliquerait le propos de cet article, de faire toutes les compilations de modules du kernel directement sur le Raspberry Pi. La compilation d’un module prend deux \u00e0 trois secondes sur un Raspberry Pi 3, ce qui est tr\u00e8s raisonnable, m\u00eame lorsque le nombre d’exemples est assez \u00e9lev\u00e9. L’inconv\u00e9nient, est que la compilation d’un module n\u00e9cessite la pr\u00e9sence des fichiers d’en-t\u00eate, du fichier de configuration et des Makefile du noyau cible. Or, les distributions Raspbian ne fournissent pas cet ensemble. Il existe bien un package linux-headers<\/em> dans cette distribution mais il ne correspond pas du tout au noyau fourni.<\/p>\n
Nous devons donc commencer par recompiler un noyau<\/strong>, op\u00e9ration tr\u00e8s simple mais qui prend environ deux heures de compilation sur le Raspberry Pi 3. En partant d’une distribution Raspbian fra\u00eechement install\u00e9e, voici la suite de commandes \u00e0 ex\u00e9cuter.<\/p>\n
$ sudo apt update<\/strong>\n$ sudo apt install -y ncurses-dev  bc<\/strong>\n$ git clone https:\/\/github.com\/raspberrypi\/linux --depth 1<\/strong>\n$ cd linux\/<\/strong>\n$ make bcm2709_defconfig<\/strong>\n$ make -j 8<\/strong>     # C'est cette \u00e9tape qui dure environ deux heures...<\/em>\n$ sudo make scripts<\/strong>\n$ sudo make modules_install<\/strong>\n$ sudo mkdir \/boot\/old-dtbs<\/strong>\n$ sudo mv \/boot\/*dtb \/boot\/old-dtbs\/<\/strong>\n$ sudo make INSTALL_DTBS_PATH=\/boot dtbs_install<\/strong>\n$ sudo cp \/boot\/kernel7.img \/boot\/old-kernel7.img<\/strong>\n$ sudo cp arch\/arm\/boot\/zImage \/boot\/kernel7.img<\/strong> \n$ sudo reboot<\/strong><\/pre>\n
Apr\u00e8s red\u00e9marrage, on v\u00e9rifie avec\u00a0:<\/p>\n
$ uname -a<\/strong><\/pre>\n
que l’on se trouve bien sur notre noyau tout neuf.<\/p>\n
Attention, le r\u00e9pertoire qui a servi pour la compilation sera r\u00e9f\u00e9renc\u00e9 pendant la compilation des modules ult\u00e9rieurs, et ne doit donc pas \u00eatre d\u00e9plac\u00e9, ni effac\u00e9. \u00c0 la rigueur, on peut y faire un peu de m\u00e9nage pour gagner de la place\u00a0:<\/p>\n
$ cd \/lib\/modules\/$(uname -r)\/build<\/strong>                                                                                  \n$ rm -rf Documentation<\/strong>\n$ find . -name '*.[coS]' | xargs rm -f<\/strong><\/pre>\n
Ceci efface les fichiers sources C et assembleur ainsi que les fichiers objets. Il est important de conserver les fichiers d’en-t\u00eate .h<\/code> et les fichiers Makefile<\/code>. On gagne ainsi environ 700\u00a0Mo.<\/p>\n
Handler d’interruption monolithique<\/h2>\n
Le cas le plus simple – et le plus courant – est celui du handler monolithique<\/strong>. Lorsque l’interruption se produit, le handler invoqu\u00e9 fait tout le travail attendu puis se termine et le processeur reprend son activit\u00e9 initiale.<\/p>\n
Un handler d’interruption s’\u00e9crit en respectant un prototype bien d\u00e9fini (il existe d’ailleurs un typedef irq_handler_t<\/code> pour repr\u00e9senter ce prototype)\u00a0:<\/p>\n
irqreturn_t irq_handler<\/em>(int irq_num<\/em>, void *irq_id<\/em>);<\/pre>\n
Lorsque le handler est appel\u00e9, il recevra automatiquement deux arguments\u00a0: le num\u00e9ro de l’interruption qui l’a d\u00e9clench\u00e9 (utile lorsque le m\u00eame handler g\u00e8re plusieurs interruptions diff\u00e9rentes), et un identifiant repr\u00e9sent\u00e9 par un pointeur g\u00e9n\u00e9rique. Nous fournirons cet identifiant lors de l’installation du handler. En g\u00e9n\u00e9ral il s’agit d’un pointeur sur une structure de donn\u00e9es personnalis\u00e9es, contenant des informations propres \u00e0 notre instance de driver.<\/p>\n
Ce pointeur joue \u00e9galement un second r\u00f4le, notamment dans le cas d’une interruption partag\u00e9e entre plusieurs p\u00e9riph\u00e9riques\u00a0: on fournit le m\u00eame pointeur lors du retrait du driver afin d’indiquer quel handler doit \u00eatre d\u00e9sinstall\u00e9.<\/p>\n
Le handler doit \u00e9galement renvoyer une valeur de type irqreturn_t<\/code>. Il s’agit d’un type \u00e9num\u00e9r\u00e9 pouvant prendre les valeurs IRQ_NONE<\/code> ou IRQ_HANDLED<\/code> (ainsi que la valeur IRQ_WAKE_THREAD<\/code> que nous verrons dans le prochain article). En principe le handler doit interroger le mat\u00e9riel qu’il g\u00e8re afin de savoir si l’interruption lui \u00e9tait bien destin\u00e9e. Dans l’affirmative il renverra IRQ_HANDLED<\/code>. Sinon, (il est probable que l’interruption soit partag\u00e9e entre plusieurs drivers) il renverra IRQ_NONE<\/code>.<\/p>\n
Pour installer et d\u00e9sinstaller le handler, on utilise les routines suivantes\u00a0:<\/p>\n
int  request_irq<\/strong>(unsigned int irq_num<\/em>, irq_handler_t irq_handler<\/em>, unsigned long flags<\/em>, const char *name<\/em>, void *irq_dev<\/em>);\nvoid free_irq<\/strong>(unsigned int irq_num<\/em>, void *irq_dev<\/em>);<\/pre>\n
Il existe divers flags<\/em> pour l’installation d’un handler, on les trouve dans le fichier <linux\/interrupt.h><\/code>. En voici quelques-uns utilis\u00e9s r\u00e9guli\u00e8rement\u00a0:<\/p>\n