Il s'agit d'un ouvrage de référence écrit par Pierre Ficheux.
Pierre Ficheux fait partie des pionniers linuxiens et a été l'un des premiers à utiliser Linux dans l'industrie.
Deux autres Linuxiens bordelais, grands spécialistes de ce domaine ont contribué à la rédaction : Eric Benard et Patrice Kadionik.
Que l'on soit décideur ou développeur, ce livre est une mine de renseignements. Deux études de cas viennent concrétiser les propos de l'auteur.
Il faut rappeler que l'embarqué est le domaine où Linux a la plus forte progression alors que les « experts » ne l'attendaient pas. Je pense que c'est dû à ce que tout le code source soit libre et que le développeur dispose de tous les outils dont il a besoin.
Nota: La traduction en anglais est prévue, mais je préfère la VO en français ;-)
Aller plus loin
- Le livre (27 clics)
# fsck /dev/seche-linge
Posté par logie tom . Évalué à 10.
Vive la démocratisation de l'informatique, et tant mieux si les Logiciels Libres sont moteurs dans le domaine.
[^] # Re: fsck /dev/seche-linge
Posté par kael . Évalué à 2.
# RT Linux
Posté par Pooly (site web personnel) . Évalué à -4.
(preemp patch, etc...)
[^] # Re: RT Linux
Posté par imalip . Évalué à 9.
[^] # Re: RT Linux
Posté par kael . Évalué à 1.
[^] # Re: RT Linux
Posté par imalip . Évalué à 3.
J'irai meme plus loin en disant que pour faire du temps réel sérieusement, il vaut mieux utiliser des plateformes addaptées. Le PC n'est pas conçu pour ca à l'origine...
[^] # Re: RT Linux
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: RT Linux
Posté par kael . Évalué à 4.
je te conseil vivement de consulter une des 42 definition de temps réél (pis ca m'evitera de lancer un troll temps réél)
sinon le preempt ne sert qu'a limiter l'impression de râmage de ton systeme quand il est chargé,il est donc nutilie sur un multiproc ;)
[^] # Re: RT Linux
Posté par Delahaye Matthieu . Évalué à 4.
Faut pas confondre une modification avec ses effets. Le preempt patch ouvre la possibilité au scheduler, dans des cas précis, de changer la tâche en cours sur un processeur à la fin d'un quantum, même lorsque celle-ci est en train d'executer un appel système, chose qui n'était pas possible avant.
Effectivement, on constate une diminution des effets de ramage, mais aussi une diminution du temps de réactivité d'une application à un évènement, même lorsque la machine ne rame pas.
Si de plus on doit comprendre "nutilie" par son anagramme inutile, le raisonnement me parait quelque peut abscon. Le fait d'avoir plusieurs procs limite mais n'empêche pas de se retrouver dans le cas d'un monoproc, i.e. voir les n processeurs chacun "occupés" par des appels systèmes. J'arrive à gagner des performances non
négligeables sur un quadri soumis à une forte charge de requêtes réseaux.
# Mouais...
Posté par Anonyme . Évalué à 3.
[^] # Re: Mouais...
Posté par kael . Évalué à 1.
hop -1 et mdr
[^] # Re: Mouais...
Posté par Antoine J. . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.