nouveau noyau linux:)

Le Mon, 24 May 2004 21:42:07 +0200, beebee a écrit :

Bonsoir,

Bonsoir,

un ami développeurviens de me parler avec conviction
du noyau de 2.6....
Il m'a dit que celui-ci étaitenfin réentrant, c'est quoi donc?????

Préemptif peut-être, mais réentrant ... Ca me rappelle le lisp
(sinistre mémoire ...).

Cela a -t-il un lien avec les noyaux temps réels?
Avec la gestion dynamique de la mémoire et des bibliothèques?

C'est aquis depuis quelque temps. Les noyaux temps réels ont des
spécificités qui ne les bornent pas au 2.6.

Voir une synthèse, il y avait encore récemment en boutique
des distibutions linux avec "noyau temps réel", disparu des rayons!?

Login en a publié voici quelques temps et les numéros peuvent encore
être achetés.

J'suis vraiment confus sur ces notions et c'est juste par curiosité:)

La curiosité sera utilement récompensée:

http://idile.org/libreast/supports/kernel2.6_sysfs.pdf

A+
jpierre

L

Bonsoir,

Bonsoir,

un ami développeurviens de me parler avec conviction
du noyau de 2.6....
Il m'a dit que celui-ci étaitenfin réentrant, c'est quoi donc?????

Préemptif peut-être, mais réentrant ... Ca me rappelle le lisp
(sinistre mémoire ...).

Cela a -t-il un lien avec les noyaux temps réels? Avec la gestion
dynamique de la mémoire et des bibliothèques?

C'est aquis depuis quelque temps. Les noyaux temps réels ont des
spécificités qui ne les bornent pas au 2.6.

Voir une synthèse, il y avait encore récemment en boutique
des distibutions linux avec "noyau temps réel", disparu des rayons!?

Login en a publié voici quelques temps et les numéros peuvent encore
être achetés.

J'suis vraiment confus sur ces notions et c'est juste par curiosité:)

La curiosité sera utilement récompensée:

http://idile.org/libreast/supports/kernel2.6_sysfs.pdf

A+
jpierre

Bonjour!

Merci, c'est exactement ce que je cherchais:)
En français en + :-)

A+
jpierre

On Mon, 24 May 2004 21:41:19 +0200, Hervé Riboulot wrote:

Le Mon, 24 May 2004 21:42:07 +0200, beebee a écrit :

Bonsoir,

Bonsoir,

un ami développeurviens de me parler avec conviction
du noyau de 2.6....
Il m'a dit que celui-ci étaitenfin réentrant, c'est quoi donc?????

Préemptif peut-être, mais réentrant ... Ca me rappelle le lisp
(sinistre mémoire ...).

Il est préemptif, ce qui impose que au moins les points d'entrés
des API (en fait, tout ce qui ne travaille pas sur des listes ou
des wait-queues) soient réentrants puique n'importe quelle routine
peut-être interrompue n'importe quand et rappelée avant d'être
reschedulée.
La ré-entrance n'est pas la récursivité, même si la dernière impose
la première. Une grosse partie du code se doit d'être réentrant,
pour éviter les crashs. Sinon, il faut abuser de locks...

Cela a -t-il un lien avec les noyaux temps réels?

Aucun. Linux est loin de supporter les contraintes d'un noyau temps-réel
et est déjà assez déficient (tout est relatif, bien sur, je veux dire
en comparaison avec un noyau temps-réel) quand il s'agit de gérer des
timings très précis: par ex envoyer des paquets bluetooth sur un
port série à 1Mbps par paquets de 64 octets en un flux synchrone
à 128 kbps, c'est loin d'être prévu pour (mais la spec l'impose...).
Pourtant, ce n'est pas bien rapide, comparé à la vitesse des CPU...

Avec la gestion dynamique de la mémoire et des bibliothèques?

C'est aquis depuis quelque temps.

Effectivement, au moins depuis le 2.0.

L

Bonsoir,

Bonsoir,

un ami développeurviens de me parler avec conviction
du noyau de 2.6....
Il m'a dit que celui-ci était enfin réentrant, c'est quoi
donc?????

Il est préemptif, ce qui impose que au moins les points d'entrés des
API (en fait, tout ce qui ne travaille pas sur des listes ou des
wait-queues) soient réentrants puique n'importe quelle routine
peut-être interrompue n'importe quand et rappelée avant d'être
reschedulée.
Oui, c'est ce qu'il m'a dit!

La ré-entrance n'est pas la récursivité, même si la

dernière impose la première. Une grosse partie du code se doit d'être
réentrant, pour éviter les crashs. Sinon, il faut abuser de locks...

Cela a -t-il un lien avec les noyaux temps réels?

Aucun. Linux est loin de supporter les contraintes d'un noyau
temps-réel et est déjà assez déficient (tout est relatif, bien sur,
je veux dire en comparaison avec un noyau temps-réel)

Oui, il semblerait aussi que les time slice
du noyau ait une possibilité de travail selon la charge:)
C'est plus uniquement un découpage unique:)
Mais bon, c'est vrai rien à voir avec la conception de beos
ou d'autres os !

Qu'appelle-t-on "tps réel" alors, le linux change de noyau?????

A+

On Tue, 25 May 2004 16:30:54 +0200, beebee wrote:

L

Bonsoir,
[...]

Cela a -t-il un lien avec les noyaux temps réels?

Aucun. Linux est loin de supporter les contraintes d'un noyau
temps-réel et est déjà assez déficient (tout est relatif, bien sur,
je veux dire en comparaison avec un noyau temps-réel)

Oui, il semblerait aussi que les time slice
du noyau ait une possibilité de travail selon la charge:)
C'est plus uniquement un découpage unique:)
Mais bon, c'est vrai rien à voir avec la conception de beos
ou d'autres os !

Non, la gestion des timeslice n'a pas changé.
La durée maximum d'un timeslice à été racourcie en faisant tourner
le timer système à 1000 Hz au lieu de 100 jusqu'alors (en fait,
c'est une option). Mais il ne change jamais...
Les processes sont interrompus (y compris les threads kernel, si
on choisit le kernel préemptif) lorsqu'ils épuisent le timeslice
ou qu'ils rentrent dans un appel système bloquant.
Par contre, le scheduler a été réécrit pour sélectionner plus
judicieusement le prochain process éligible et essayer d'optimiser le
temps de recherche de ce process...

Qu'appelle-t-on "tps réel" alors, le linux change de noyau?????

Linux n'est pas et, à en croire Mr Torvalds, ne sera jamais temps-réel.
Il ne faut pas confondre noyau temps-réel et API POSIX temps réel..
Cette API, implémentée par Linux (et déjà dans le 2.4) concerne les
entrées sorties asynchrones (les appels-systèmes aio_xxx) et un modèle
de signaux gérés par des queues, qui peuvent donc être délivrés
également de façon asynchrone.
Rien à voir avec un kernel temps-réel qui est un noyau qui garantit
qu'une tache donnée sera exécutée dans un temps fixe (ou maximisé)
et synchronisé sur des évènements extérieurs, autrement dit,
en temps-réel...
La gestion de ces contraintes est très couteuse et les noyaux temps-réels
sont moins rapides que les noyaux "standard", contrairement à ce qu'on
s'imagine souvent.
Linux est au contraire optimisé pour aller le plus vite possible,
en évitant au maximum de s'imposer des contraintes d'execution.
C'est peu compatible avec le temps-réel, comme principe de conception...

L

Bonsoir,
bonjour:)

Cela a -t-il un lien avec les noyaux temps réels?

Aucun. Linux est loin de supporter les contraintes d'un noyau
temps-réel et est déjà assez déficient (tout est relatif, bien sur,
je veux dire en comparaison avec un noyau temps-réel)

Oui, il semblerait aussi que les time slice
du noyau ait une possibilité de travail selon la charge:)
C'est plus uniquement un découpage unique:) Mais bon, c'est vrai rien
à voir avec la conception de beos
ou d'autres os !

Non, la gestion des timeslice n'a pas changé. La durée maximum d'un
timeslice à été racourcie en faisant tourner le timer système à 1000
Hz au lieu de 100 jusqu'alors (en fait, c'est une option). Mais il ne
change jamais...

Oui, mais 10 fois plus rapide, c'est pas rien:)

Les processes sont interrompus (y compris les threads

kernel, si on choisit le kernel préemptif) lorsqu'ils épuisent le
timeslice ou qu'ils rentrent dans un appel système bloquant. Par contre,
le scheduler a été réécrit pour sélectionner plus judicieusement le
prochain process éligible et essayer d'optimiser le temps de recherche de
ce process...

C'est vrai que l'impression de rapidité et de réactivité
des dernières versions est vraiment perceptible pas les utilisateurs:)

Qu'appelle-t-on "tps réel" alors, le linux change de noyau?????

Linux n'est pas et, à en croire Mr Torvalds, ne sera jamais temps-réel.
Il ne faut pas confondre noyau temps-réel et API POSIX temps réel..
Cette API, implémentée par Linux (et déjà dans le 2.4) concerne les
entrées sorties asynchrones (les appels-systèmes aio_xxx) et un modèle
de signaux gérés par des queues, qui peuvent donc être délivrés
également de façon asynchrone.
Rien à voir avec un kernel temps-réel qui est un noyau qui garantit
qu'une tache donnée sera exécutée dans un temps fixe (ou maximisé) et
synchronisé sur des évènements extérieurs, autrement dit, en
temps-réel...
La gestion de ces contraintes est très couteuse et les noyaux
temps-réels sont moins rapides que les noyaux "standard", contrairement
à ce qu'on s'imagine souvent.
Linux est au contraire optimisé pour aller le plus vite possible, en
évitant au maximum de s'imposer des contraintes d'execution. C'est peu
compatible avec le temps-réel, comme principe de conception...

Merci pour toutes ses explications:)
J'avais moi aussi compris que les contraintes temps réels sont liée à
des processus industriles pilotage de robots, certaines technologies dans
le domaine médical....

A+
jpierre