Eric L : >>Le noyau de Linux est préemptible (avec l'option qui va bien selectionnée lors de la config)
-> il ne s' agit pas de la même chose, je pense que tu le sais. C' est un module temps-réel (un linux security module) ce qui est différent d' un kernel preemption on acid
Quand je disais ça je répondais uniquement à Christophe Cazajus :
tous les appels système pourront
être préempté - ce qui est loin d'être le cas actuellement.
-----------------
Sinon quand tu dis "un module temps-réels (un linux security module)", il n'y a strictement aucun rapport entre un LSM et le temps réel.
La péemption en mode noyau est une caractérisque commune aux noyaux RT. Les patchs de Love, Morton, permettent justement cela (on a soit un appel direct au scheduler par les tâches soit c'est en sortant de certains chemins noyau (ex. retour en usermode, etc.)) que le flag NEED_RESCHED (positionné lors du traitement d'une interruption par ex) est testé et s'il est positionné, on fait appel au scheduler.). Ensuite, il y a beaucoup d'autres choses à modifier afin d'obtenir un noyau RT dur, et c'est ce à quoi se démène Ingo et Ted (préemption des spinlocks, etc.). Bref...
Le vrai terme "système temps-réel" pourrait être "système prédictible"
Ce n'est pas suffisant, il faut la propriété de déterminisme également.
Un watchdog (dont Eric L parle également ici) tournant en temps-réel se chargeant de la sécurité.
C'est un certain Christophe Cazajus qui parle de watchdog...
sinon le watchdog se charge de la sûreté de fonctionnement (safety) et _non_ de la sécurité au sens security !!!
Les deux solutions présentées par défaut dans tout kernel sont toutes des "temps-réel mous".
ben non... (par ex. VMware s'est pour du RT dur). Encore une fois, le temps réel est dit dur lorsque l'on a besoin d'avoir des _garanties_ sur les _échéances_ (Le temps de traitement peut très bien être important, ça dépend du système à piloter). Et ces dites garanties doivent être prouvées mathématiquement (RMA, etc.). Le RT mou est quant à lui adapté pour les traitements audio ou vidéo, car une garantie au sens math n'est pas nécessaire (il n'y a pas risque de mort)...
Bref, il ya beaucoup de chose à dire... En tout cas il n'y a pas d'intérêt d'avoir un Linux patché RT dur pour une station de travail (c'est hors propos)..
[^] # Re: priority inheritance... encore un pas de plus :)
Posté par Eric Lacombe . En réponse à la dépêche Sortie du noyau Linux 2.6.18. Évalué à 2.
-> il ne s' agit pas de la même chose, je pense que tu le sais. C' est un module temps-réel (un linux security module) ce qui est différent d' un kernel preemption on acid
Quand je disais ça je répondais uniquement à Christophe Cazajus :
tous les appels système pourront
être préempté - ce qui est loin d'être le cas actuellement.
-----------------
Sinon quand tu dis "un module temps-réels (un linux security module)", il n'y a strictement aucun rapport entre un LSM et le temps réel.
La péemption en mode noyau est une caractérisque commune aux noyaux RT. Les patchs de Love, Morton, permettent justement cela (on a soit un appel direct au scheduler par les tâches soit c'est en sortant de certains chemins noyau (ex. retour en usermode, etc.)) que le flag NEED_RESCHED (positionné lors du traitement d'une interruption par ex) est testé et s'il est positionné, on fait appel au scheduler.). Ensuite, il y a beaucoup d'autres choses à modifier afin d'obtenir un noyau RT dur, et c'est ce à quoi se démène Ingo et Ted (préemption des spinlocks, etc.). Bref...
Le vrai terme "système temps-réel" pourrait être "système prédictible"
Ce n'est pas suffisant, il faut la propriété de déterminisme également.
Un watchdog (dont Eric L parle également ici) tournant en temps-réel se chargeant de la sécurité.
C'est un certain Christophe Cazajus qui parle de watchdog...
sinon le watchdog se charge de la sûreté de fonctionnement (safety) et _non_ de la sécurité au sens security !!!
Les deux solutions présentées par défaut dans tout kernel sont toutes des "temps-réel mous".
ben non... (par ex. VMware s'est pour du RT dur). Encore une fois, le temps réel est dit dur lorsque l'on a besoin d'avoir des _garanties_ sur les _échéances_ (Le temps de traitement peut très bien être important, ça dépend du système à piloter). Et ces dites garanties doivent être prouvées mathématiquement (RMA, etc.). Le RT mou est quant à lui adapté pour les traitements audio ou vidéo, car une garantie au sens math n'est pas nécessaire (il n'y a pas risque de mort)...
Bref, il ya beaucoup de chose à dire... En tout cas il n'y a pas d'intérêt d'avoir un Linux patché RT dur pour une station de travail (c'est hors propos)..