[fedora-fr-doc] Doc Mise en oeuvre du patch PREEMPT-RT

Patrice metal3d at gmail.com
Mer 17 Déc 16:10:34 CET 2008


Le 17 décembre 2008 15:52, Patrice Kadionik <kadionik at enseirb.fr> a écrit :
> Patrice a écrit :
>> J'ai plutôt l'impression que tu n'es pas impartial vue la teneur
>> garantie en passion dans tes propos :) Je te taquine mais je reste
>>
> Je suis impartial justement. j'aime que les choses soient précises,
> c'est tout...
>> dans l'optique que matraquer à tout vas dans la doc "temps réel mou"
>> peut prêter à une image un peu néfaste du travail effectué.
>>
> Pourquoi, dire la vérité te gêne ?
> L'embarqué demande rigueur et honnêté.
> J'ai plus l'impression que tu as peur de vexer un mainteneur assez
> susceptible mais qui ne conteste pas le côté soft real time du patch...
>

Mais non... c'est juste que je tente de comprendre et de faire la part
des choses... tu y vas véhéments comme si c'était une infamie de
réduire quelques termes alors que je ne fais que poser des questions
après de retours du mainteneur du boulot...

Ce que je cherche c'est simplement d'utiliser les bons termes... je
vois pas pourquoi tu t'énerves

>
>> Comme je te le disais, si le temps réel est "mou" par nature dans
>> l'informatique, il n'est pas "faux" de parler de temps réel sans
>> spécifier à chaque fois "mou". Par contre, introduire en expliquant
>> que le temps réel qui sera utilisable est "mou" dans l'intro est une
>> bonne optique.
>>
>> Bref, je reprendrai cette conversation plus tard, je suis noyé sous le
>> boulot moi
>>
>>
> Arg ! Le "moi" est en trop !!!

J'ai pas dis que j'étais le seul soit dit en passant ;)

> Sache que j'ai passé 2 h à corriger ton document.
> Maintenant, fais comme tu veux... j'aurai simplement l'impression
> d'avoir perdu 2 h...
>

Genre cette phrase là... qui est un peu vache... j'ai passé 6 heures
entre les tests et l'écriture du document... je te remercie d'avoir
bossé sur la relecture mais si c'est pour m'en envoyer plein la
tronche je préfère honnêtement que tu ne corriges pas... tant pis
hein...

Sérieusement, sans rire vas-y cool on est entre amis là et j'ai
franchement l'impression que de parler avec le mainteneur qui spécifie
certains points et d'en parler ici te gène fortement... comme si je
t'agressais... alors que je ne fais que causer d'un sujet qui
m'intéresse fortement...

Ou alors je comprend pas le ton de tes réponses, chose qui arrive
souvent sur les ML ou IRC... on a l'impression que le mec gueule alors
qu'en fait il cause simplement, si c'est le cas excuse moi :)


> pk
>> Le 17 décembre 2008 12:54, Patrice Kadionik <kadionik at enseirb.fr> a écrit :
>>
>>> Re,
>>>
>>> Ca va devenir une querelle de spécialistes...
>>> Patrice a écrit :
>>>
>>>> Le souci c'est que Steven a l'air de se contrer à cette optique car le
>>>> TR proposé par le patch ne correspond pas franchement à du temps réel
>>>> mou. Il parle d'ailleur du fait que de dire "soft RT" est limite
>>>> insultant (http://en.wikipedia.org/wiki/Pet_peeve si vous lisez sa
>>>> réponse)
>>>>
>>>> Le patch RT proposé par Ingo et maintenant Steven ne correspond pas à
>>>> du temps réel mou proposé de base dans les options de compilation de
>>>> kernel. Le terme PREEMPT-RT est certes plus adéquat (car on ne
>>>> spécifie pas mou ou dur :) ).
>>>>
>>>>
>>> oui, le patch PREEMPT-RT est meilleur en moyenne en temps de latence que
>>> les patchs trditionnels kpreempt ou low latency dans le noyau.
>>> Jusqu'à preuve du contraire, preempt-rt est du même acabit : on n'est
>>> pas sûr d'avoir dans 100 % des cas un temps de latence borné et garanti.
>>> Pourquoi il existe des systèmes à conoyaux comme RTLinux, RTAI et
>>> maintenant Xenomai.
>>>
>>> maintenant, on va tomber sur un problème d'égo. Ce n'est pas parce qu'on
>>> maintient un projet qu'on ne raconte pas de bêtises...
>>> Si l'on veut être honnête intellectuellement, on NE DOIT PAS parler
>>> aujourd'hui de Temps Réel tout court à cause de cette  c... de Temps
>>> Réel mou. On doit préciser.
>>> preempt-rt reste TR mou même si c'est l'un des meilleurs patchs.
>>> Je pense qu'il faut laisser le terme "mou". C'est la réalité...
>>>
>>>
>>>> Mais si Steven exprime justement ce souci de terme, je pense qu'il est
>>>> bon d'en parler... Quand je parle de mono kernel, je veux dire que le
>>>> temps réel dur comme tu le spécifie est implémenté en général avec
>>>> deux instance de noyau, chose que le patch ne propose pas.
>>>>
>>>> Mon souci c'est que Steven a l'air de bonne fois et comme en plus
>>>> c'est lui qui continue le développement de ce patch (patch énorme
>>>> d'ailleurs puisqu'il impacte un énormément de sources dans le noyau),
>>>> j'ai tendance à vouloir écouter son opinion aussi...
>>>>
>>>> Il a bossé dans l'électronique et connait aussi le sujet, il exprime
>>>> justement ce que tu dis en terme de "life or death operating systems".
>>>> Si le terme "mou" est limite insultant pour eux et que en plus il n'a
>>>> pas vraiment de sens dans l'informatique (car comme tu le dis si bien,
>>>> en informatique on ne parle finalement que de temps réel mou... à
>>>> moins d'avoir deux machine et deux kernel prévu pour cela et dans ce
>>>> cas on tape dans une solution matérielle) alors pourquoi devrait-on
>>>> spécifier "mou" ?
>>>>
>>>> Surtout que ce terme peut prêter à confusion, on m'a envoyé un mail me
>>>> demandant pourquoi utiliser un truc lent peut améliorer le système...
>>>> je pense que "noter" ou "faire remarquer" que le temps réel proposé
>>>> par le patch est du temps réel mou est plus adéquat que d'insister en
>>>> précisant à chaque fois le terme "temps réel mou".
>>>>
>>>>
>>> simplement pour ne pas tromper les gens car dans leur inconscient :
>>> TEMPS REEL=TEMPS DUR  ce qui est faut ici....
>>>
>>>> Je suis de ton avis en ce qui concerne le principe, mais de l'avis de
>>>> Steven en ce qui concerne l'insistance du terme. Je pense que le plus
>>>> important est de parler de temps réel, et de notifier en intro ou en
>>>> conclusion que dans l'info on ne parle que rarement de temps réel
>>>> dur...
>>>>
>>>>
>>> non. Le temps réel est dans la majeure partie des cas du temps réel dur
>>> dans la "vraie vie".
>>> Le temps réel mou est récent et n'assure qu'une certaine QoS dont on a
>>> besoin dans le multimédia...
>>>
>>> Si tu ne veux pas choquer, tu mets dans la doc en intro que preempt-rt
>>> est TR mou ainsi que dans la conclusion... Tu peux mettre Temps Réel
>>> tout court dans le reste.
>>> Il faut être précis, rigoureurx, honnête et impartial même si ça peut
>>> heurter qq égos... On a le droit d'être critique et impartial non ?
>>>
>>> Patrice
>>>
>>>> Le 17 décembre 2008 11:24, Patrice Kadionik <kadionik at enseirb.fr> a écrit :
>>>>
>>>>
>>>>> Salut.
>>>>>
>>>>> Le temps Réel mou est une notion inventé par les informaticiens il y a
>>>>> qq années.
>>>>> Pour l'électronicien, il n'existe que le Temps Reel dur ou Temps Réel.
>>>>>
>>>>> J'ai donné la différence dans :
>>>>> http://doc.fedora-fr.org/wiki/Fedora_Core_et_le_Temps_R%C3%A9el
>>>>>
>>>>> Patrice a écrit :
>>>>>
>>>>>
>>>>>> Bonjour à tous,
>>>>>> J'ai un petit soucis en ce qui concerne le terme de "temps réel mou"
>>>>>> et "temps réel dur"... Je vais vous expliquer le pourquoi.
>>>>>>
>>>>>> Comme je commence à packager un kernel RT, je me suis dis que le mieux
>>>>>> serait de contacter Ingo Molnar... chose que j'ai fait.
>>>>>>
>>>>>> Ce dernier m'a réorienté vers le nouveau mainteneur de ce patch qui
>>>>>> est Steven Rostedt. J'ai donc put échangé avec lui et lorsque je
>>>>>> parlais de soft real time (temps réel mou), Steven a répondu en ces
>>>>>> termes:
>>>>>>
>>>>>> "I will comment on the 'soft real time'.
>>>>>> This is a pet peeve[1] of mine. The term soft real time means that the
>>>>>> system can miss a deadline and still be OK. When someone is using the -rt
>>>>>> patch, and they miss their dead line, then that is a bug. It is not OK.
>>>>>> Thus, the -rt patch is really meant to be 'hard real time'. The problem is
>>>>>> that the term 'hard real time' is associated with life or death operating
>>>>>> systems like airplane engine controls (which I have worked on).
>>>>>>
>>>>>> The difference between a RTOS that is on a airplane and the linux rt
>>>>>> kernel, is that one has been tested much harder. The goal is still the
>>>>>> same (guaranteed latency), but the amount of effort to prove it can make
>>>>>> the deadline is under stricter guidelines in the airplane engine OS than it
>>>>>> is in a factory making cars.
>>>>>>
>>>>>> What I'm trying to state, is that there is no such thing as 'hard real
>>>>>> time' or 'soft real time'. There is only 'real time' with different levels
>>>>>> of quality assurance ;-)"
>>>>>>
>>>>>> Si je comprend bien, le patch RT n'est pas vraiment un patch pour
>>>>>> faire du temps réel dur ni mou... c'est bien du temps réel... avec un
>>>>>> niveau acceptable de qualité.
>>>>>>
>>>>>> En tout cas il a l'air contre l'idée d'appeler (ou du moins de
>>>>>> préciser) que c'est du temps réel "MOU". C'est d'ailleurs un point de
>>>>>> vue que je partage puisque le principe du patch est largement au delà
>>>>>> d'un niveau de preemption mou... on est proche du temps réel dur avec
>>>>>> la contrainte de mono kernel... si vous me suivez...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Dans l'embarqué et le TR, c'est soit blanc soit noir... Tu est TR dur ou
>>>>> pas...
>>>>> L'ambiguité tient au faut qu'on met sous TR le TR dur et le TR mou des
>>>>> informaticiens.
>>>>> PREEMPT-RT est TR mou...
>>>>> "on est proche du temps réel dur avec la contrainte de mono kernel" ne
>>>>> veut rien dire. Tu l'es ou pas. Es-tu sûr que dans 100 % des cas le
>>>>> temps de latence est borné avec PREEMPT-RT ? Non.
>>>>> Donc c'est du TR mou...
>>>>> J'ai déjà eu cette conversation à Solutions Linux 2008. Linux avec tous
>>>>> les patchs d'amélioration de la préemption ne le rendront pas TR dur...
>>>>> L'arnaque est de parler de Temps Réel tout court aujourd'hui. IL FAUT
>>>>> PRECISER DUR OU NON DUR SOIT MOU MAINTENANT ! C'est tromper les gens
>>>>> sinon ! Je sais que les informaticiens parlent de Temps Réel tout court
>>>>> car ils ne savent pas trop ce que ça veut dire et induit.
>>>>>
>>>>> Je sais que l'on a raison de dire PREEMPT-RT est TR mou. Je ne suis pas
>>>>> le seul à le dire aussi. P. Ficheux aussi.
>>>>>
>>>>> ++
>>>>> Patrice
>>>>>
>>>>>
>>>>>> Bref, selon les termes de Steven, je devrai expliquer cela dans la
>>>>>> doc... vous pensez pas ?
>>>>>>
>>>>>>
>>>>>> Le 16 décembre 2008 12:00, Patrice <metal3d at gmail.com> a écrit :
>>>>>>
>>>>>>
>>>>>>
>>>>>>> En relisant mon article je me suis rendu compte que nous pouvions
>>>>>>> faire un peu mieux...
>>>>>>> D'abord j'ai ajouté "l'astuce" pour la phase de compilation de noyau
>>>>>>> qui consiste à ajouter l'option "-j 3" pour les processeur dual-core
>>>>>>> ou multi-proc
>>>>>>>
>>>>>>> Ensuite, ce que je n'ai pas fait, c'est d'ajouter une méthode plus
>>>>>>> "propre" au niveau de grub qui consiste non pas à éditer le fichier à
>>>>>>> la main mais d'utiliser soit grubby soit new-kernel-pkg (je suis en
>>>>>>> cours de tests puisque je package depuis peu un noyau RT pour créer
>>>>>>> Fedora Studio).
>>>>>>>
>>>>>>> Je me suis mis en relation avec Ingo Molnar qui m'a appris que ce
>>>>>>> n'est plus lui qui gère ces travaux mais Steven-Rostedt depuis
>>>>>>> quelques temps. Je pourrais certainement avoir quelques infos à
>>>>>>> ajouter dans l'article.
>>>>>>>
>>>>>>>
>>>>>>> L'aricle a l'air bien en place, on l'ajoute dans la doc (rublrique) ?
>>>>>>>
>>>>>>> --
>>>>>>> http://www.metal3d.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> Patrice Kadionik. F6KQH / F4CUQ
>>>>> -----------
>>>>>
>>>>> +----------------------------------------------------------------------+
>>>>> +"Tout doit etre aussi simple que possible, pas seulement plus simple" +
>>>>> +----------------------------------------------------------------------+
>>>>> + Patrice Kadionik             http://www.enseirb.fr/~kadionik         +
>>>>> + IMS Laboratory               http://www.ims-bordeaux.fr/             +
>>>>> + ENSEIRB                      http://www.enseirb.fr                   +
>>>>> + PO BOX 99                    fax   : +33 5.56.37.20.23               +
>>>>> + 33402 TALENCE Cedex          voice : +33 5.56.84.23.47               +
>>>>> + FRANCE                       mailto:patrice.kadionik at ims-bordeaux.fr +
>>>>> +----------------------------------------------------------------------+
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> fedora-fr-doc mailing list
>>>>> fedora-fr-doc at fedora-fr.org
>>>>> http://mailing-list.fedora-fr.org/mailman/listinfo/fedora-fr-doc
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>> --
>>> Patrice Kadionik. F6KQH / F4CUQ
>>> -----------
>>>
>>> +----------------------------------------------------------------------+
>>> +"Tout doit etre aussi simple que possible, pas seulement plus simple" +
>>> +----------------------------------------------------------------------+
>>> + Patrice Kadionik             http://www.enseirb.fr/~kadionik         +
>>> + IMS Laboratory               http://www.ims-bordeaux.fr/             +
>>> + ENSEIRB                      http://www.enseirb.fr                   +
>>> + PO BOX 99                    fax   : +33 5.56.37.20.23               +
>>> + 33402 TALENCE Cedex          voice : +33 5.56.84.23.47               +
>>> + FRANCE                       mailto:patrice.kadionik at ims-bordeaux.fr +
>>> +----------------------------------------------------------------------+
>>>
>>>
>>> _______________________________________________
>>> fedora-fr-doc mailing list
>>> fedora-fr-doc at fedora-fr.org
>>> http://mailing-list.fedora-fr.org/mailman/listinfo/fedora-fr-doc
>>>
>>>
>>
>>
>>
>>
>
>
> --
> Patrice Kadionik. F6KQH / F4CUQ
> -----------
>
> +----------------------------------------------------------------------+
> +"Tout doit etre aussi simple que possible, pas seulement plus simple" +
> +----------------------------------------------------------------------+
> + Patrice Kadionik             http://www.enseirb.fr/~kadionik         +
> + IMS Laboratory               http://www.ims-bordeaux.fr/             +
> + ENSEIRB                      http://www.enseirb.fr                   +
> + PO BOX 99                    fax   : +33 5.56.37.20.23               +
> + 33402 TALENCE Cedex          voice : +33 5.56.84.23.47               +
> + FRANCE                       mailto:patrice.kadionik at ims-bordeaux.fr +
> +----------------------------------------------------------------------+
>
>
> _______________________________________________
> fedora-fr-doc mailing list
> fedora-fr-doc at fedora-fr.org
> http://mailing-list.fedora-fr.org/mailman/listinfo/fedora-fr-doc
>



-- 
http://www.metal3d.org


Plus d'informations sur la liste de diffusion fedora-fr-doc