Articles précédents : Développeur
- [22] Crise dans la gestion de fichier
- [12] Concours de programmation de Vie Artificielle
- [41] Bientôt le noyau Linux 3.0 ?
- [9] Bibliothèques matricielles pour C et C++
- [26] Gestion de la mémoire virtuelle du noyau 2.5.x
- [11] Assembleur "PowerPC"
- [102] Les promesses de la Native POSIX Threading Library et du prochain Kernel 2.6
- [2] Rendezvous en open source
- [1] BEA annonce la disponibilité de sa machine virtuelle Java optimisée pour Intel
- [29] La journalisation XFS intégrée au noyau 2.5.*
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 ;-)
![[fr]](../../../images/fr.png)
Le livre (2252 hits)
> Lire la dépêche (12 commentaires, moyenne: 3,8).
fsck /dev/seche-linge
C'est vrai: un frigo ou un telephone sous linux, c'est pas que pour les geeks. ;)
Vive la démocratisation de l'informatique, et tant mieux si les Logiciels Libres sont moteurs dans le domaine.
-
[^]Re: fsck /dev/seche-linge
[+] RT Linux
Cette progression n'est pas aussi du au fait que le noyau est aussi concu pour le RT ?
(preemp patch, etc...)
-
[^]Re: RT Linux
Posté par imalip (page perso, ) le 09/10/2002 à 07:44. (lien). Évalué à 9.Le noyau Linux n'est pas concu pour le temps réel. Meme les patch preempt ou low-latency ne sont pas suffisant. Pour s'approcher du temps réel, il faut utiliser des API spécifiques (avec patch+modules noyau). Par exemple RTLinux ou RTAI. Là, on te propose les fonctions idoines.
--
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal-
[^]Re: RT Linux
Posté par kael () le 09/10/2002 à 08:24. (lien). Évalué à 1.ahhh RTlinux, ou la joyeuse bidouille :) le principe est un peu porc mais ca marche pas trop mal mais bon faut etre réaliste si on veut un noyau unix temps réél utilisable correctement en industrie on se tournera plutot vers des solution proprio comme lynxOS ou QNX (qui est gratos maintenant)
-
[^]Re: RT Linux
Posté par imalip (page perso, ) le 09/10/2002 à 08:32. (lien). Évalué à 3.Je n'ai jamais dit que RTLinux ou RTAI (RTAI mieux, RTAI GPL. RTLinux brevets, beurk) n'utilisait pas une méthode barbare. Je suis sur ce point tout à fait d'accord avec toi.
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...--
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
-
[^]Re: RT Linux
Posté par LupusMic (page perso, ) le 10/10/2002 à 16:36. (lien). Évalué à 2.Pourtant, RTLinux n'est pas si libre que ça ... vas voir leur(s) license(s).
-
-
-
[^]Re: RT Linux
Posté par kael () le 09/10/2002 à 08:19. (lien). Évalué à 4.rhoooo!!! confondage entre le preemptif et le temps reel !!!!
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 () le 09/10/2002 à 12:06. (lien). Évalué à 4.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 ;)
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...
Pour la domotique (Linux embarqué dans les appareils ménagers), ce n'est pas la peine d'utiliser Linux alors que MultideskOS existe: http://users.skynet.be/bk240090/fr/domoai.htm(...)
-
[^]Re: Mouais...
Posté par kael () le 09/10/2002 à 08:21. (lien). Évalué à 1.ouha !!! quelle systeme merveilleux !!! et je peu l'embarquer dans une boulangerie aussi ?
hop -1 et mdr-
[^]Re: Mouais...
Posté par Antoine J. (Jabber id, ) le 09/10/2002 à 09:54. (lien). Évalué à 3.Bien sûr et comme ça, si un client rentre, tu pourra être prévenu par une sonnerie alors que tu moule dans l'arrière boutique.
-
Cette page a été générée par Templeet en 0.0821s (dont 0.0098 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.