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.
Archives de la catégorie ‘Linux’
Clean Code: A Handbook of Agile Software Craftsmanship
Robert C. Martin
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 :
J’ai remarqué une question récurrente, tant durant mes sessions de formation sur Linux industriel qu’au cours de prestations d’ingénierie concernant des systèmes temps-réel ou embarqués : « Quelles sont les options du noyau qui influent sur [un sujet donné] ? » Le sujet en question a généralement trait aux mécanismes d’ordonnancement, à la vitesse de boot, à la taille du code produit, etc.
(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.
Nous avons examiné dans l’article précédent comment compiler une bibliothèque dynamique et gérer correctement ses numéros majeurs et mineurs de version afin d’en faciliter la maintenance, tant pour le développeur (de la bibliothèque mais aussi pour celui des applications qui l’utilisent) que pour l’administrateur du système sur lequel elle est installée. Nous allons à présent examiner comment effectuer le débogage de notre bibiliothèque et des applications qui l’appellent.
(Version originale en français)
In the previous article we saw how to build a dynamic library and properly manage its major and minor version numbers for easy maintenance, both for the developer (of the library but also of the applications that use it) and for the administrator of the system where it is installed. We will now consider how to debug our library and applications that call it.
Lors d’une récente session de formation, une conversation avec un participant m’a poussé à vérifier les options nécessaires pour effectuer du débogage et des tests en couverture sur une bibliothèque partagée.
(Version originale en français)
During a recent training session, a conversation with a participant gave me the idea to check the options needed to perform debugging and coverage tests on a shared library.
