Comme beaucoup d’entre vous le savent déjà, la Freebox v.6 a raté son passage à l’heure d’été. Ce matin, alors que mon PC, ma montre et mon téléphone affichent 09:44, la Freebox posée à côté de mon bureau affiche encore 08:44. Au-delà du fait divers amusant, source de plaisanteries et de sarcasmes sur Twitter, je trouve cette mésaventure intéressante, car elle trouve son origine dans des logiciels que connaissent bien les amateurs de Linux embarqué !
J’ai été plusieurs fois confronté à la nécessité de déterminer le temps de réveil d’une tâche utilisateur. La plupart du temps il s’agit de borner le temps de réaction face à un événement extérieur qui se traduit par une interruption (nous en verrons un exemple dans un prochain article). Récemment toutefois, le problème qui se posait était de réveiller un processus lorsque le contenu d’une adresse mémoire (projetée par une carte d’acquisition) était modifié. Aucune interruption n’érait déclenchée à cette occasion, aussi la seule solution était de venir scruter en polling cette adresse régulièrement dans un timer du noyau. Une fois la modification détectée, il fallait acquiter l’événement ce qui était réalisé dans le kernel, sans présenter de caractère d’urgence. Après l’acquitement il faillait toutefois entamer un traitement dans l’espace utilisateur le plus rapidement possible. J’avais donc besoin de mesurer le temps de réveil d’une tâche depuis un timer du noyau.
Dans le précédent article, nous avons examiné les options du menu General Setup à prendre particulièrement en considération lors de la préparation d’un noyau Linux pour un système embarqué ou temps-réel.
Examinons à présent d’autres options proposées dans un menu dont le nom varie légèrement suivant les architectures :
(english translation here)
Nous avons commencé la mise au point d’une bibliothèque dynamique sous Linux dans les deux articles précédents : dans le premier nous avons vu comment compiler la bibliothèque et gérer les numéros de versions à l’aide de liens symboliques, dans le second nous avons effectué du suivi d’appel et du débogage pas-à-pas. Nous allons désormais nous intéresser à la vérification de la couverture de la bibliothèque.
(version originale en français ici)
In the two previous posts, we started the development of a dynamic library on Linux: the first one saw us building the library and managing version numbers using symbolic links, in the second one we traced library calls and did step-by-step debugging. Now we are interested in checking the coverage of the library.


