La méthode de communication entre processus la plus performante lorsqu’on doit transférer des données volumineuses est l’emploi de zones de mémoires partagées. Standardisé par Posix, il s’agit d’un mécanisme extrémement efficace. Toutefois, il faut penser à synchroniser les accès, afin d’éviter les modifications concurrentes des données partagées ou la modification d’une zone pendant sa consultation par un autre processus.
Lire la suite de cette entrée »
Archives de la catégorie ‘Linux’
Tout est dans le titre… Le site kernel.org, victime d’une attaque fin août, était inaccessible depuis près d’un mois.
Il est à nouveau actif partiellement, même si un certain nombre de fonctionnalités sensibles (accès SSH par exemple) ont été désactivées pour un moment encore. De même les archives des noyaux (même les liens proposés en première page) ne sont pas disponibles pour l’instant.
N’oublions pas que d’autres projets (Linux-RT par exemple) sont centralisés aussi sur ce serveur, et que nous sommes nombreux à espérer son retour prochain.
Nous avions examiné dans l’article précédent de cette série un premier mécanisme de communication entre processus : les files de messages Posix. Nous avions observé qu’il était facile de transmettre un message de quelques kilo-octets entre deux processus, en un temps allant de 8 microsecondes si le processeur était déjà actif à 15 microsecondes si les messages étaient suffisament espacés pour laisser au processeur le temps de s’endormir et de prendre un temps de réveil non négligeable.
Nous allons à présent observer les possibilités liées aux signaux temps-réel Posix.1b.
Un client m’a demandé récemment de le conseiller sur le choix d’un mécanisme de communication entre processus pour transférer rapidement des données entre deux applications. Il existe plusieurs systèmes d’IPC (Inter Process Communication), chacun avec ses avantages et inconvénients, et j’ai eu envie de les comparer pour déterminer le plus rapide, en fonction du type de données à transférer. Ce premier article est consacré aux message queues, les files de messages.
Depuis une semaine, un sujet de discussion s’est répandu sur la plupart des sites consacrés à Linux : la sécurité du site http://www.kernel.org/ a été compromise durant la fin août. Ce serveur est le point central de distribution des sources des noyaux Linux.
L’intrus a apparemment obtenu des accréditations SSH par l’intermédiaire d’une machine appartenant à Hans Peter Anvin. Les traces découvertes le 28 août suggèrent que le système SSH et des scripts de démarrage ont été compromis, entre autres. Naturellement les administrateurs ne divulguent pas encore le détail de l’attaque.
Je vais être amené à présenter très prochainement une session de formation professionnelle sur Linux temps-réel et embarqué dans une entreprise où l’administrateur système ne veut pas installer Gnu/Linux sur les postes de formation ! N’ayant pas les compétences pour installer une partition Linux, il ne tolère que le boot sur systèmes live (CD ou Clé USB).
Kernel panic – not syncing: No init found.
J’indiquais dans un article précédent (à la fin de « Construire son système personnel pour Pandaboard – 1« ) que ce message était pour moi une excellente nouvelle, car il indiquait que le noyau avait correctement démarré, identifié les périphériques et trouvé son système de fichiers initial. Une excellente nouvelle lorsqu’on construit un système embarqué. Pas lorsque le message se présente sur mon poste de travail principal ! Voici donc une mésaventure qui m’est arrivé cette semaine.
Dans les applications temps-réel il est très important d’éviter les situations dites « d’inversion de priorité ». Il s’agit de cas dans lesquels une tâche de haute priorité est bloquée en attente de la terminaison d’une tâche de plus faible priorité alors qu’elles n’ont rien en commun.
Absent depuis quelques jours (pour cause de Festival d’Avignon) je n’ai pas encore salué le basculement définitif sur la branche 3.0 du noyau Linux survenu vendredi dernier. Un peu plus tôt que je l’imaginais initialement.
