Debian possède ENFIN un noyau entièrement libre...

Le Wed, 22 Dec 2010 11:06:29 -0800 (PST),
remy <remy.aumeunier@libertysurf.fr> écrivait :

On 22 déc, 19:27, crouic <lacig...@no-log.org> wrote:

>> Je ne comprend pas pourquoi la traduction (voire la version
>> originale) n'emploie pas le terme de driver/pilote pour les
>> translators/traducteurs, puisqu'ils sont des serveurs servant à ça.
>> Ou alors j'ai rien compris ^^

> ?
> Là il faut faire appel à un plus grand spécialiste des
> (micro-)noyaux, c'est encore légèrement flou :) . Demandons à JKB à
> tout hasard...

> Sinon les traducteurs ne sont pas forcément des pilotes pour le
> matériel, ils servent à représenter quelque chose sous la forme d'un
> système de fichier (si je ne dis pas de bêtises). Par exemple on peut
> avoir un traducteur représentant l'arbre des discussions de ce groupe
> sous forme d'un ensemble de fichiers/répertoire.

Je traduis une doc, cela me permet de retenir ce que je lit. Je passerai le lien
s'il y a des amateurs.
Ce ne sont pas des pilotes effectivement, c'est plus que cela. La philosophie
"tout est fichier" est poussée à l'extrême et les "pilotes" actuels seraient des
fichiers spéciaux, qui se brancheraient sur d'autres fichiers spéciaux tels les
périphériques. Finalement, tout ce monde est en mode utilisateur, et chacuns
peut se connecter au autres, et l'objectif est la liberté maximale pour
l'utilisateur qui gère les inter-connexions comme il le souhaite, changer chaque
partie du système sans droits particuliers, et sans reboot. On peut même
enchaîner les micro-noyaux ^^.

Mais une question reste sans réponse, il puisqu'il y a des personnes qualifiées
sur ce fil j'en profite: si les limitations des micro-noyaux sont les
basculements en mode noyau/utilisateur et les IPC, l'architecture actuelle des
microprocesseurs n'est-elle pas en cause ? N'est-elle pas (trop) optimisée pour
le noyaux monolithiques, ou bien le basculement de mode est-il une tare de type
386 trainée comme un boulet ?

Je ne suis pas un vrai spécialiste du micro noyaux

mais les services sont en théorie un user-land
et doivent communiquer avec le « noyaux maitre en mode protéger»

Non, c'est faux. D'ailleurs, il n'y a pas grand monde qui cause avec
le micronoyau lui-même. Juste la roottask pour des besoins bien
spécifiques.

j'excite ,je suis libre /occupe,avec une communication synchrone/
asynchrone
bufferisation des msg ,ect

Non, c'est en général faux. Les messages peuvent être parfaitement
synchrones. C'est même souhaitable.

et multiplier les services c'est multiplier les appels systèmes
et un appel système c'est tout sauf anodin en terme de ressource
utilisee, je ne suis pas sur que l'architecture hard y soit pour
quelque chose

Comment dire... Tous les OS font des appels système et il n'y a
_aucune_ raison valable pour qu'un OS à micronoyau en fasse plus
qu'un autre. Et pour ce qui concerne les pilotes, si dans un noyau
monolithique, ça ne passe pas par IPC, il y a des mécanismes qui les
remplacent et qui consomment aussi du temps CPU.

Les micronoyaux modernes ont des systèmes de fenêtres de registres
virtuels qui sont très efficaces.

mes 3 centimes d'euro

Ça ne vaut pas plus.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Le 22/12/2010 20:18, JKB a écrit :

Comment dire... Tous les OS font des appels système et il n'y a
_aucune_ raison valable pour qu'un OS à micronoyau en fasse plus
qu'un autre. Et pour ce qui concerne les pilotes, si dans un noyau
monolithique, ça ne passe pas par IPC, il y a des mécanismes qui les
remplacent et qui consomment aussi du temps CPU.

Les micronoyaux modernes ont des systèmes de fenêtres de registres
virtuels qui sont très efficaces.

Je trouve ça passionnant, mais je ne suis pas spécialiste en systèmes
d'exploitations, ce qui rend la compréhension hardue, limite abstraite.
Par exemple la différence entre fils et thread est-elle du même gabarit que
celle entre un processus et une tâche, un processus sans ce-qui-va-bien pour
être POSIX ?

JFK, si tu as de la doc technique, je suis preneur ;)

Je traduis une doc, cela me permet de retenir ce que je lit. Je
passerai le lien s'il y a des amateurs.

Oui :) .

Le Wed, 22 Dec 2010 21:49:20 +0100,
crouic <lacigale@no-log.org> écrivait :

Le 22/12/2010 20:18, JKB a écrit :

Comment dire... Tous les OS font des appels système et il n'y a
_aucune_ raison valable pour qu'un OS à micronoyau en fasse plus
qu'un autre. Et pour ce qui concerne les pilotes, si dans un noyau
monolithique, ça ne passe pas par IPC, il y a des mécanismes qui les
remplacent et qui consomment aussi du temps CPU.

Les micronoyaux modernes ont des systèmes de fenêtres de registres
virtuels qui sont très efficaces.

Je trouve ça passionnant, mais je ne suis pas spécialiste en systèmes
d'exploitations, ce qui rend la compréhension hardue, limite abstraite.
Par exemple la différence entre fils et thread est-elle du même gabarit que
celle entre un processus et une tâche, un processus sans ce-qui-va-bien pour
être POSIX ?

Je ne sais trop, ce sont deux choses différentes. Un thread pour un
micronoyau est un fil d'exécution qui inclut un pointeur sur
l'instruction en cours, un contexte (sauvegarde des registres en cas
de changement de contexte) et une pile, le tout dans un espace
d'adressage. Tu peux donc avoir plusieurs programmes qui sont
totalement disjoints, lancés comme des fils d'exécution dans le même
espace d'adressage. Ce ne sont pas des threads au sens Unix du terme
puisque sous Unix, un processus est dans un espace d'adressage
propre et tous les threads sont issus de ce processus à coups de
pthread_create() ou équivalent. Ce ne sont pas des processus non
plus puisqu'ils tournent dans le même espace mémoire et peuvent
partager des données.

JFK, si tu as de la doc technique, je suis preneur ;)

http://www.l4ka.org/projects/pistachio/

C'est rude, il faut se faire un noeud au cerveau pour comprendre
comment ça fonctionne, mais c'est élégant.

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

JKB a écrit :

Le Wed, 22 Dec 2010 11:06:29 -0800 (PST),
remy <remy.aumeunier@libertysurf.fr> écrivait :

On 22 déc, 19:27, crouic <lacig...@no-log.org> wrote:

Je ne comprend pas pourquoi la traduction (voire la version
originale) n'emploie pas le terme de driver/pilote pour les
translators/traducteurs, puisqu'ils sont des serveurs servant à ça.
Ou alors j'ai rien compris ^^

?
Là il faut faire appel à un plus grand spécialiste de s
(micro-)noyaux, c'est encore légèrement flou :) . Demandon s à JKB à
tout hasard...
Sinon les traducteurs ne sont pas forcément des pilotes pour le
matériel, ils servent à représenter quelque chose sou s la forme d'un
système de fichier (si je ne dis pas de bêtises). Par exem ple on peut
avoir un traducteur représentant l'arbre des discussions de ce groupe
sous forme d'un ensemble de fichiers/répertoire.

Je traduis une doc, cela me permet de retenir ce que je lit. Je passe rai le lien
s'il y a des amateurs.
Ce ne sont pas des pilotes effectivement, c'est plus que cela. La phi losophie
"tout est fichier" est poussée à l'extrême et les "pil otes" actuels seraient des
fichiers spéciaux, qui se brancheraient sur d'autres fichiers sp éciaux tels les
périphériques. Finalement, tout ce monde est en mode utilis ateur, et chacuns
peut se connecter au autres, et l'objectif est la liberté maxima le pour
l'utilisateur qui gère les inter-connexions comme il le souhaite , changer chaque
partie du système sans droits particuliers, et sans reboot. On p eut même
enchaîner les micro-noyaux ^^.

Mais une question reste sans réponse, il puisqu'il y a des perso nnes qualifiées
sur ce fil j'en profite: si les limitations des micro-noyaux sont les
basculements en mode noyau/utilisateur et les IPC, l'architecture act uelle des
microprocesseurs n'est-elle pas en cause ? N'est-elle pas (trop) opti misée pour
le noyaux monolithiques, ou bien le basculement de mode est-il une ta re de type
386 trainée comme un boulet ?

Je ne suis pas un vrai spécialiste du micro noyaux

mais les services sont en théorie un user-land
et doivent communiquer avec le « noyaux maitre en mode proté ger»

Non, c'est faux. D'ailleurs, il n'y a pas grand monde qui cause avec
le micronoyau lui-même. Juste la roottask pour des besoins bien
spécifiques.

tu deviens lourd
aller zou un cour qui traine sur ma machine, il vient de la toille

page 66

http://cjoint.com/data/0mxjwpEJ4vS.htm

j'excite ,je suis libre /occupe,avec une communication synchrone/
asynchrone
bufferisation des msg ,ect

Non, c'est en général faux. Les messages peuvent être p arfaitement
synchrones. C'est même souhaitable.

et multiplier les services c'est multiplier les appels systèmes
et un appel système c'est tout sauf anodin en terme de ressource
utilisee, je ne suis pas sur que l'architecture hard y soit pour
quelque chose

Comment dire... Tous les OS font des appels système et il n'y a
_aucune_ raison valable pour qu'un OS à micronoyau en fasse plus
qu'un autre. Et pour ce qui concerne les pilotes, si dans un noyau
monolithique, ça ne passe pas par IPC, il y a des mécanismes qui les
remplacent et qui consomment aussi du temps CPU.

Les micronoyaux modernes ont des systèmes de fenêtres de reg istres
virtuels qui sont très efficaces.

fait une recherche sur les bus logiciel
cela va de qt avec les signaux, aux bus usb ,en passent par corba



remy



--
http://remyaumeunier.chez-alice.fr/

Le Thu, 23 Dec 2010 09:26:53 +0100,
remy <remy@fctpas.fr> écrivait :

tu deviens lourd
aller zou un cour qui traine sur ma machine, il vient de la toille

page 66

http://cjoint.com/data/0mxjwpEJ4vS.htm

Prends au moins des références sérieuses. Ce papier est un tissu
d'inexactitudes (enfin, pas pire que les tiennes) et de conneries.
Il y a deux ou trois trucs justes dans le tas, mais il faut vraiment
avoir l'oeil pour les trouver. Par ailleurs, il a été écrit à une
époque ou il n'existait pas de micronoyau sérieux (Mach n'est _pas_
un micronoyau) et où les seuls vrais micronoyaux étaient
asynchrones. Discuter de performances est donc ridicule.

Dans un premier temps, le type mélange allègrement les micronoyaux
avec les noyaux hybrides. Ses remarques sur les performances
comparées sont donc vaines (et contredites par RTOS par exemple, qui
lui, tourne sur un micronoyau au sens strict du terme).
Quant à ses explications sur les machines virtuelles, c'est du grand
art (un micronoyau n'a aucune raison de connaître ce qu'il appelle
un _acteur_, puisque c'est un serveur dédié qui doit gérer les accès
aux ressources).

Un conseil, regarde plutôt les cours d'OKL qui sont disponibles sur
le grand ternet, ça t'évitera de comprendre à moitié des tas de
bêtises.

j'excite ,je suis libre /occupe,avec une communication synchrone/
asynchrone
bufferisation des msg ,ect

Non, c'est en général faux. Les messages peuvent être parfaitement
synchrones. C'est même souhaitable.

et multiplier les services c'est multiplier les appels systèmes
et un appel système c'est tout sauf anodin en terme de ressource
utilisee, je ne suis pas sur que l'architecture hard y soit pour
quelque chose

Comment dire... Tous les OS font des appels système et il n'y a
_aucune_ raison valable pour qu'un OS à micronoyau en fasse plus
qu'un autre. Et pour ce qui concerne les pilotes, si dans un noyau
monolithique, ça ne passe pas par IPC, il y a des mécanismes qui les
remplacent et qui consomment aussi du temps CPU.

Les micronoyaux modernes ont des systèmes de fenêtres de registres
virtuels qui sont très efficaces.

fait une recherche sur les bus logiciel
cela va de qt avec les signaux, aux bus usb ,en passent par corba

J'aimerais bien que tu m'expliques ce que vient faire Corba et les
bus USB là-dedans. Tu peux trouver du Corba dans des choses comme
IDL mais c'est un truc inutile dans l'immense majorité des cas.
C'est à toi de gérer tes protocoles à la main de façon efficace. Tu
ne peux pas te plaindre après avoir utilisé Corba que les
performances sont ridicules. Pour ton information, un thread L4 ne
fait des appels systèmes (avec changement de contexte) qu'en cas :
- d'I/O (via la roottask et le serveur de nom qui redirige) ;
- de défaut de page (via son propre pager embarqué dans le même
espace mémoire, donc avec un temps de latence faible puisque ce
n'est que lorsque le pager embarqué remonte lui-même un défaut de
page que le pager du système [en userland] traite la faute) ;
- d'interruption.

Le nombre de changements de contextes est donc assez faible pour peu
que tu fasses les choses intelligemment.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

JKB a écrit :

Le Thu, 23 Dec 2010 09:26:53 +0100,
remy <remy@fctpas.fr> écrivait :

tu deviens lourd
aller zou un cour qui traine sur ma machine, il vient de la toille

page 66

http://cjoint.com/data/0mxjwpEJ4vS.htm

Prends au moins des références sérieuses. Ce papier est un tissu
d'inexactitudes (enfin, pas pire que les tiennes) et de conneries.
Il y a deux ou trois trucs justes dans le tas, mais il faut vraiment
avoir l'oeil pour les trouver. Par ailleurs, il a été é crit à une
époque ou il n'existait pas de micronoyau sérieux (Mach n'es t _pas_
un micronoyau) et où les seuls vrais micronoyaux étaient
asynchrones. Discuter de performances est donc ridicule.

Dans un premier temps, le type mélange allègrement les micro noyaux
avec les noyaux hybrides. Ses remarques sur les performances
comparées sont donc vaines (et contredites par RTOS par exemple, qui
lui, tourne sur un micronoyau au sens strict du terme).
Quant à ses explications sur les machines virtuelles, c'est du gr and
art (un micronoyau n'a aucune raison de connaître ce qu'il appell e
un _acteur_, puisque c'est un serveur dédié qui doit gé rer les accès
aux ressources).

Un conseil, regarde plutôt les cours d'OKL qui sont disponibles s ur
le grand ternet, ça t'évitera de comprendre à moitié des tas de
bêtises.

j'excite ,je suis libre /occupe,avec une communication synchrone/
asynchrone
bufferisation des msg ,ect

Non, c'est en général faux. Les messages peuvent être parfaitement
synchrones. C'est même souhaitable.

et multiplier les services c'est multiplier les appels systèmes
et un appel système c'est tout sauf anodin en terme de ressourc e
utilisee, je ne suis pas sur que l'architecture hard y soit pour
quelque chose

Comment dire... Tous les OS font des appels système et il n'y a
_aucune_ raison valable pour qu'un OS à micronoyau en fasse plu s
qu'un autre. Et pour ce qui concerne les pilotes, si dans un noyau
monolithique, ça ne passe pas par IPC, il y a des mécanism es qui les
remplacent et qui consomment aussi du temps CPU.

Les micronoyaux modernes ont des systèmes de fenêtres de r egistres
virtuels qui sont très efficaces.

fait une recherche sur les bus logiciel
cela va de qt avec les signaux, aux bus usb ,en passent par corba

J'aimerais bien que tu m'expliques ce que vient faire Corba et les
bus USB là-dedans.

ok

la communication usb (host/client) passe par un bus logiciel asynchrone
la communication corba passe par un bus logiciel le plus souvent
synchrone un annuaire et une communication ( client /serveur)

http://www.sylbarth.com/corba/corba.html

tout la programmation événementiel qt par exemple passe par un bus
logiciel asynchrone ou virtuelle ou a msg comme tu veux (d-bus pour qt)
la communication IPC passe par un bus logiciel le plus souvent synchrone
bus synchrone, bus synchrone ha oui comme corba alors :-)




remy





--
http://remyaumeunier.chez-alice.fr/

remy a écrit :

JKB a écrit :

Le Thu, 23 Dec 2010 09:26:53 +0100,
remy <remy@fctpas.fr> écrivait :

tu deviens lourd
aller zou un cour qui traine sur ma machine, il vient de la toille

page 66

http://cjoint.com/data/0mxjwpEJ4vS.htm

Prends au moins des références sérieuses. Ce papier est un tissu
d'inexactitudes (enfin, pas pire que les tiennes) et de conneries.
Il y a deux ou trois trucs justes dans le tas, mais il faut vraime nt
avoir l'oeil pour les trouver. Par ailleurs, il a été à ©crit à une
époque ou il n'existait pas de micronoyau sérieux (Mach n'est _pas_
un micronoyau) et où les seuls vrais micronoyaux étaient
asynchrones. Discuter de performances est donc ridicule.

Dans un premier temps, le type mélange allègrement les m icronoyaux
avec les noyaux hybrides. Ses remarques sur les performances
comparées sont donc vaines (et contredites par RTOS par exemp le, qui
lui, tourne sur un micronoyau au sens strict du terme).
Quant à ses explications sur les machines virtuelles, c'est d u grand
art (un micronoyau n'a aucune raison de connaître ce qu'il ap pelle
un _acteur_, puisque c'est un serveur dédié qui doit gà ©rer les accès
aux ressources).

Un conseil, regarde plutôt les cours d'OKL qui sont disponibl es sur
le grand ternet, ça t'évitera de comprendre à moiti é des tas de
bêtises.

j'excite ,je suis libre /occupe,avec une communication synchrone/
asynchrone
bufferisation des msg ,ect

Non, c'est en général faux. Les messages peuvent ê tre parfaitement
synchrones. C'est même souhaitable.

et multiplier les services c'est multiplier les appels système s
et un appel système c'est tout sauf anodin en terme de ressour ce
utilisee, je ne suis pas sur que l'architecture hard y soit pour
quelque chose

Comment dire... Tous les OS font des appels système et il n 'y a
_aucune_ raison valable pour qu'un OS à micronoyau en fasse plus
qu'un autre. Et pour ce qui concerne les pilotes, si dans un noy au
monolithique, ça ne passe pas par IPC, il y a des méca nismes qui
les
remplacent et qui consomment aussi du temps CPU.

Les micronoyaux modernes ont des systèmes de fenêtres de registres
virtuels qui sont très efficaces.

fait une recherche sur les bus logiciel
cela va de qt avec les signaux, aux bus usb ,en passent par corba

J'aimerais bien que tu m'expliques ce que vient faire Corba et les
bus USB là-dedans.

ok

la communication usb (host/client) passe par un bus logiciel asynchrone
la communication corba passe par un bus logiciel le plus souvent
synchrone un annuaire et une communication ( client /serveur)

http://www.sylbarth.com/corba/corba.html

tout la programmation événementiel qt par exemple passe par un bus
logiciel asynchrone ou virtuelle ou a msg comme tu veux (d-bus pour qt)
la communication IPC passe par un bus logiciel le plus souvent synchron e
bus synchrone, bus synchrone ha oui comme corba alors :-)

bus asynchrone
un evenemnt
je poste 'et ca merde'
et basta

bus synchrone
un evenement
je poste 'et ca merde'
oh j'attends moi


remy



--
http://remyaumeunier.chez-alice.fr/

Le Thu, 23 Dec 2010 11:22:27 +0100,
remy <remy@fctpas.fr> écrivait :

JKB a écrit :

J'aimerais bien que tu m'expliques ce que vient faire Corba et les
bus USB là-dedans.

ok

la communication usb (host/client) passe par un bus logiciel asynchrone
la communication corba passe par un bus logiciel le plus souvent
synchrone un annuaire et une communication ( client /serveur)

http://www.sylbarth.com/corba/corba.html

tout la programmation événementiel qt par exemple passe par un bus
logiciel asynchrone ou virtuelle ou a msg comme tu veux (d-bus pour qt)
la communication IPC passe par un bus logiciel le plus souvent synchrone
bus synchrone, bus synchrone ha oui comme corba alors :-)

Et après, on écrit des conneries comme 'les micronoyaux sont lents'.
Un micronoyau, il fonctionne avec des projections en mémoire (d'un
espace à l'autre). Les IPC sont donc très rapides par rapport à
celles d'un noyau hybride comme Mach. Dans L4/X2, seules les
transmissions de StringItem_t sont lentes parce que faites par copie
de lé mémoire. Utiliser Corba (comme c'est fait dans iguana) est une
immense connerie, mais tu as le droit de la faire. C'est d'ailleurs
assez cohérent avec l'utilisation de java. On cache tout un tas de chose
pour soi-disant faire simple et au final c'est lent.

Et je ne vois toujours pas la relation évidente entre la
programmation système et qt. On n'est pas sur le même plan et on
n'utilise surtout pas les mêmes techniques. Au passage, ce qu'on
appelle message dans l'architecture des micronoyaux modernes n'a
strictement rien à voir avec un message au sens Unix du terme. De
grâce, ne mélange pas tout, déjà que tu ne semble pas trop maîtriser
le sujet. Ah si, en gros et de loin...

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Le 23/12/2010 00:22, JKB a écrit :

Le Wed, 22 Dec 2010 21:49:20 +0100,

JFK, si tu as de la doc technique, je suis preneur ;)

http://www.l4ka.org/projects/pistachio/

C'est rude, il faut se faire un noeud au cerveau pour comprendre
comment ça fonctionne, mais c'est élégant.

Cordialement,

JKB

Merci, moi qui voulait avoir une vue d'ensemble... :D
Il se trouve que j'ai commencé à la potasser ce matin même, c'est du technique
pur avec le nombre de bits par registre, etc. Mais la lecture est en cours.