Pour mettre tout le monde d'accord: Window9

Le 21-07-2009, ? propos de
Re: Pour mettre tout le monde d'accord: Window9,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :

JKB wrote:

Pas du tout. Un OS est POSIX ou il ne l'est pas. Cygwin, c'est du
userland, et c'est une _émulation_ des bibliothèques POSIX, émulation
parce que rien n'est prévu dans Windows pour cela et que ça reste en
userland (à moins
que le fonctionnement du bouzin ait été revu récemment, je ne suis plus
le développement de cygwin). Maintenant, si tu considères que ça rend
Windows POSIX, c'est ton problème et pas le mien. Fin de la discussion sur
ce point.

Parce que POSIX necessite forcement que tout soit au niveau kernel ?

J'aimerais bien que tu m'expliques comment tu implantes la
libpthread proprement sans être dans le kernelland. C'est une vraie
question et j'attends une réponse. Et j'ai demandé une réponse avec une
implantation "propre" et non un verrou qui bloque tout en étant _à peu
près_ sûr que les opérations du thread restant soient atomiques.

C'est nouveau ?

Windows NT est POSIX.1, on peut lui adjoindre des complements qui lui
permettent d'ameliorer sa compatibilite POSIX aux versions superieures.
Ensuite, si on implemente toutes les API qu'il faut sur un Windows et
qu'il passe tous les tests de conformites, Windows est tout aussi POSIX
que n'importe quel Unix (je pense meme qu'il doit pouvoir aller plus
loin que certains Unix).

Windows NT4 POSIX.1 ? C'est nouveau, ça ! Lorsqu'on voit que
certaines fonctions de base POSIX renvoient sous Unix un const char et
sous Windows un char * qu'il faut libérer, tu me permettras de me marrer !

POSIX c'est avant tout une API de developement, des interfaces
utilisateurs, la presence d'utilitaires, la definition de flags sur les
fichiers ... rien n'empeche de repondre a toutes ces conditions sur un
Windows (ou sur presque n'importe quoi qui sait compiler du C, qui est
multi-taches, multi-utilisateurs et qui sait gerer potablement des
droits).

Il y avait meme des couches POSIX sur certains mainframes, les dinos
confirmeront.

Oui, et alors ?

Aller je te donne un exemple d'un appel POSIX :

sleep()
CONFORMING TO
POSIX.1-2001.

Tu m'expliques ce qui t'interdis d'avois un unistd.h et la lib qui va
bien pour avoir un sleep() sous Windows ? rien, d'ailleurs, avec Cygwin,
ca marche tres bien.

Parce que la spécificité POSIX, c'est un tantinet plus compliqué que
la disponibilité de certaines fonctions POSIX comme sleep().
Effectivement, sleep(), tu peux l'implanter partout, mais tu as des
trucs largement plus complexe à mettre en oeuvre pour avoir le label
POSIX.

Il y a des tas de bouts de code qui ne compilent ou fonctionnent
correctement que sous Linux (il suffit de regarder les trucs 'linux
specific' dans les manuels).

Il y a des tas de merdes partout. Le fait est simplement que Cygwin
comme Linux utilisent principalement la suite de logiciel GNU pour se
constituer et que se faisant, on retrouve les memes programmes sur les
deux.

Mais la liaison entre les deux, c'est pas Linux, c'est GNU.

Non. La liaison entre les deux, ce sont les développeurs plus que
tout le reste. En cela, les linuxeries de la libc se retrouvent dans
Cygwin (modulo la gestion de certains drapeaux des signaux qu'il
faudrait implanter en kernelland sous Windows).

Cygwin aurait pu reprendre les logiciels BSD a la base (qui reprennent
aussi du GNU parfois), mais ce n'est pas le cas.

vient de Solaris ou de HP-UX, voire d'OpenVMS/POSIX, tu risques d'avoir
quelques surprises, ne serait-ce qu'au niveau de la gestion des signaux
POSIX. Je te prie de croire que j'ai donné !

C'est possible. On aura d'ailleurs les memes problemes sous Linux ou en
croisant de Solaris a HP-UX. Ca n'a rien de specifique a Cygwin ou
Windows.

Ne fait surtout pas semblant de ne pas comprendre.

Je n'ai pas dit que ça émulait un système au niveau des binaires. Ça
émule un fonctionnement POSIX sur un OS qui ne l'est pas.

Un emulateur est un logiciel qui emule un comportement hardware.

Un logiciel qui simule un autre logiciel est un "simulateur".

Posix n'est pas un logiciel, POSIX c'est une norme. On repond ou on ne
repond pas a la norme, mais on ne la simule pas.

Ne change pas de débat, parce que la distinction
émulateur/simulateur dans le cas de Cygwin est très ténue (au passage,
j'ai contribué il y a longtemps à ce truc pour ce qui concerne les
drapeaux des signaux POSIX, donc j'ai une vague idée de ce que je
raconte).

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

JKB wrote:

J'aimerais bien que tu m'expliques comment tu implantes la
libpthread proprement sans être dans le kernelland. C'est une vraie

D'abord il n'y a pas une norme POSIX, mais pas moins de 17
documents differents qui definissent un ensemble de points au quels les
systemes repondent plus ou moins.

Personne n'a dit que Cygwin avait implemente l'ensemble de la
normalisation POSIX (pas plus que les BSD d'ailleurs). Pas besoin
d'aller aussi loin que la gestion des thread, pdt longtemps mkfifo ne
fonctionnait pas sous Cygwin.

Ca n'en fait pas plus un emulateur pour autant.

Windows NT4 POSIX.1 ? C'est nouveau, ça ! Lorsqu'on voit que
certaines fonctions de base POSIX renvoient sous Unix un const char et
sous Windows un char * qu'il faut libérer, tu me permettras de me marrer !

http://fr.wikipedia.org/wiki/Posix
http://support.microsoft.com/kb/149902
http://cygwin.com/ml/cygwin/2001-03/msg01875.html

...

Encore une fois, personne n'a dit qu'une implementation devait complete
et propre. Mais ca n'en fait pas un emulateur pour autant.

Parce que la spécificité POSIX, c'est un tantinet plus compliqué que
la disponibilité de certaines fonctions POSIX comme sleep().
Effectivement, sleep(), tu peux l'implanter partout, mais tu as des
trucs largement plus complexe à mettre en oeuvre pour avoir le label
POSIX.

On s'en fout du label POSIX, la n'est pas le probleme. FreeBSD n'a pas
le label POSIX, ca n'en fait pas moins un Unix.

Non. La liaison entre les deux, ce sont les développeurs plus que
tout le reste. En cela, les linuxeries de la libc se retrouvent dans
Cygwin (modulo la gestion de certains drapeaux des signaux qu'il
faudrait implanter en kernelland sous Windows).

On s'en fout ou il faudrait l'implementer. POSIX ne definit pas ou les
choses doivent etre implementees. POSIX definit quelles sont les
fonctions qui doivent etre disponibles et comment elles doivent reagir.

Ne change pas de débat, parce que la distinction
émulateur/simulateur dans le cas de Cygwin est très ténue (au passage,
j'ai contribué il y a longtemps à ce truc pour ce qui concerne les
drapeaux des signaux POSIX, donc j'ai une vague idée de ce que je
raconte).

Tu ne connais meme pas la definition des mots que tu emploies et tu
viens donner des lecons. Il n'y a rien de tenue dans tout cela, Cygwin
n'est ni un simulateur, ni un emulateur de la norme POSIX.
Principalement, parce qu'on n'emule pas une norme, on l'implemente.

C'est une implementation (incomplete) de la norme POSIX sous Windows.

La definition de Wikipedia est assez exacte en soit : Cygwin se compose
d'une bibliothèque qui implémente l'API système de POSIX en faisant
appel au système Win32.

Plus haut, ils disent aussi que "permettant à différentes versions de
Windows de Microsoft d'émuler un système Unix". Je trouve cette
definition moins propre, mais encore correcte dans le sens on si on
assimile un systeme Unix (on ne parle pas de Posix, mais d'Unix) a un
ensemble OS+software+hardware, en effet, cygwin permet d'emuler cet
ensemble sous Windows. Mais cela n'a rien a voir avec la notion
d'implemtation POSIX.

Le 21-07-2009, ? propos de
Re: Pour mettre tout le monde d'accord: Window9,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :

JKB wrote:

J'aimerais bien que tu m'expliques comment tu implantes la
libpthread proprement sans être dans le kernelland. C'est une vraie

D'abord il n'y a pas une norme POSIX, mais pas moins de 17
documents differents qui definissent un ensemble de points au quels les
systemes repondent plus ou moins.

Personne n'a dit que Cygwin avait implemente l'ensemble de la
normalisation POSIX (pas plus que les BSD d'ailleurs). Pas besoin
d'aller aussi loin que la gestion des thread, pdt longtemps mkfifo ne
fonctionnait pas sous Cygwin.

Bon, du blablatage à la Tougard, comme d'habitude. Je n'ai jamais
prétendu que Cygwin doit suivre la norme POSIX. Il y a simplement un
ensemble de fonctions qui doivent fonctionner de la même façon sous
Cygwin que sous n'importe quel Unix pour prétendre pouvoir compiler un
code venu du monde Unix sous Cygwin. Et cela passe entre autre par un
bout de la norme Posix. Le fait que l'OS sous-jacent ne permette pas
certaines manipulations et que celles-ci sont fournies par une couche
userland pose un certain nombre de problèmes (et c'est même pour cela
que autoconf/automake proposent des tests pour savoir si tu es sous
Cygwin ou pas). Maintenant, que tu te contrefiches d'essayer de
comprendre la limitation d'une _émulation_ Posix dans Cygwin, je ne vais
pas perdre de temps à te l'expliquer. Et Cygwin a un _autre_ problème de
taille, il est relié aux développeurs de la glibc, ce qui fait qu'on
retrouve dans Cygwin une partie des aberrations de la glibc.

Au fait, pour ta gouverne :

En inform., émulation signifie ,,Simulation d'un ordinateur d'un
certain type sur un ordinateur d'un autre type`` (Lar. encyclop. Suppl.
1975).

Simulation : ,,Étude du comportement d'un certain type d'ordinateur par un
autre type`` (LAUZEL-MUSS. 1970).

On est donc dans le cas de Cygwin dans une _émulation_.

De la même manière, en électronique, on émule avec un bout de soft
et on simule avec un bout de hard.

Fin de la discussion. Tu peux continuer à asséner des
contre-vérités, à me traiter d'imbécile, venant de toi, j'en ai
l'habitude.

JKB

JKB wrote:

Bon, du blablatage à la Tougard, comme d'habitude. Je n'ai jamais
prétendu que Cygwin doit suivre la norme POSIX. Il y a simplement un
ensemble de fonctions qui doivent fonctionner de la même façon sous
Cygwin que sous n'importe quel Unix pour prétendre pouvoir compiler un
code venu du monde Unix sous Cygwin. Et cela passe entre autre par un
bout de la norme Posix. Le fait que l'OS sous-jacent ne permette pas
certaines manipulations et que celles-ci sont fournies par une couche
userland pose un certain nombre de problèmes (et c'est même pour cela
que autoconf/automake proposent des tests pour savoir si tu es sous
Cygwin ou pas). Maintenant, que tu te contrefiches d'essayer de
comprendre la limitation d'une _émulation_ Posix dans Cygwin, je ne vais
pas perdre de temps à te l'expliquer. Et Cygwin a un _autre_ problème de
taille, il est relié aux développeurs de la glibc, ce qui fait qu'on
retrouve dans Cygwin une partie des aberrations de la glibc.

Et c'est toi qui parle de blablatage ?

Au fait, pour ta gouverne :

En inform., émulation signifie ,,Simulation d'un ordinateur d'un
certain type sur un ordinateur d'un autre type`` (Lar. encyclop. Suppl.
1975).

Exact. POSIX n'est pas un ordinateur, POSIX n'est meme pas un systeme.
POSIX, c'est une norme qui impose la presence d'API, d'utilitaires ...

Unix est un systeme qui implemente tout ou partie de la norme POSIX,
Cygwin est un emulateur Unix qui implemente en partie la norme POSIX
sous Windows.

On est donc dans le cas de Cygwin dans une _émulation_.

Une emulation d'Unix, c'est exact. Mais cela n'a strictement rien a voir
avec POSIX.

Fin de la discussion. Tu peux continuer à asséner des
contre-vérités, à me traiter d'imbécile, venant de toi, j'en ai
l'habitude.

C'est beau, on dirait un melange entre le petit Nicolas et pipolin.

Le 22-07-2009, ? propos de
Re: Pour mettre tout le monde d'accord: Window9,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :

JKB wrote:

Bon, du blablatage à la Tougard, comme d'habitude. Je n'ai jamais
prétendu que Cygwin doit suivre la norme POSIX. Il y a simplement un
ensemble de fonctions qui doivent fonctionner de la même façon sous
Cygwin que sous n'importe quel Unix pour prétendre pouvoir compiler un
code venu du monde Unix sous Cygwin. Et cela passe entre autre par un
bout de la norme Posix. Le fait que l'OS sous-jacent ne permette pas
certaines manipulations et que celles-ci sont fournies par une couche
userland pose un certain nombre de problèmes (et c'est même pour cela
que autoconf/automake proposent des tests pour savoir si tu es sous
Cygwin ou pas). Maintenant, que tu te contrefiches d'essayer de
comprendre la limitation d'une _émulation_ Posix dans Cygwin, je ne vais
pas perdre de temps à te l'expliquer. Et Cygwin a un _autre_ problème de
taille, il est relié aux développeurs de la glibc, ce qui fait qu'on
retrouve dans Cygwin une partie des aberrations de la glibc.

Et c'est toi qui parle de blablatage ?

Au fait, pour ta gouverne :

En inform., émulation signifie ,,Simulation d'un ordinateur d'un
certain type sur un ordinateur d'un autre type`` (Lar. encyclop. Suppl.
1975).

Exact. POSIX n'est pas un ordinateur, POSIX n'est meme pas un systeme.
POSIX, c'est une norme qui impose la presence d'API, d'utilitaires ...

Unix est un systeme qui implemente tout ou partie de la norme POSIX,
Cygwin est un emulateur Unix qui implemente en partie la norme POSIX
sous Windows.

On est donc dans le cas de Cygwin dans une _émulation_.

Une emulation d'Unix, c'est exact. Mais cela n'a strictement rien a voir
avec POSIX.

Fin de la discussion. Tu peux continuer à asséner des
contre-vérités, à me traiter d'imbécile, venant de toi, j'en ai
l'habitude.

C'est beau, on dirait un melange entre le petit Nicolas et pipolin.

C'est plus fort que moi... Je te renvoie le compliment. Au fait,
j'attends la réponse à la question posée sur le fait qu'il est possible
d'écrire une implantation Posix en userland. Je te donne un indice.
Lorsque je contribuais à Cygwin, tous les programmes étaient
indépendants (comprendre, Cygwin n'était pas une machine virtuelle, je
ne sais pas ce qu'il en est aujourd'hui). Comment mets-tu donc en
pratique les specs Posix dans un tel cas _sans_ passer par le noyau de
l'OS, ici, Windows ? Question subsidiaire : si Posix demande des choses
qui ne sont pas prévues par le noyau de l'OS hôte, comment fais-tu pour
les assurer proprement en userland (sans avoir un truc qui rame
excessivement, ce qui est le cas de Cygwin) ? Et des trucs imposés par
Posix et qui ne sont pas dans Windows, il y en a des tas.

Maintenant, écrire une couche d'émulation Posix sur mainframe, c'est
_beaucoup_ plus facile que sous Windows car la plupart des prérequis
sont disponibles sur tous les mainframes. Pour fixer les idées, sous
VMS, il est possible de programmer en C de façon proche du matériel (on
peut aller jusqu'à utiliser les interruptions). Écrire une couche Posix
pour transformer VMS en OpenVMS a donc été simple et le résultat est un
truc efficace et utilisable.

Comme à ton habitude, tu vas encore dire que lorsque tu compiles un
truc sous Cygwin, ça fonctionne. Peut-être, mais c'est dû à des
'workarounds' partout dans le code. Un code Posix natif n'a _aucune_
raison de bien tourner sous Cygwin sans modification sérieuses dès lors
que le programme en question est un peu plus évolué que 'hello, world !'.
Pour ma part, j'ai même arrêté de vérifier le fonctionnement de mes
programmes sous Cygwin (et de contribuer à Cygwin) depuis quelque temps
parce que je n'ai pas le temps de trouver les 'workarounds' nécessaires
au bon fonctionnement de mes programmes.

Au fait, une implantation Unix, ça ne veut rien dire. Que tu dises
implantation BSD, implantation SysVr4 ou autre, ça a un sens.
Implantation Unix, c'est vague et ça ne veut strictement rien dire.

Maintenant, réponds sur le fond si tu en est capable, ce dont je
doute fortement.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

JKB wrote:

C'est plus fort que moi... Je te renvoie le compliment. Au fait,
j'attends la réponse à la question posée sur le fait qu'il est possible
d'écrire une implantation Posix en userland. Je te donne un indice.

Mais t'as rien compris au film toi.

Le probleme n'est pas d'ecrire dans le kernel, dans l'userland ou dans
un plateau de fromage. Le probleme est de repondre aux normes et
d'implementer les API, interfaces et logiciels.

Ca peut etre fait comme un gros porc dans une grosse libc toute pourrie,
de facon tres propre et tres decoupee avec les bonnes choses au bon
endroits, ca ne change rien que la finalite est d'implementer une norme
et de reussir une serie de tests qui garantissent une confirmite plus ou
moins reussie.

Lorsque je contribuais à Cygwin, tous les programmes étaient
indépendants (comprendre, Cygwin n'était pas une machine virtuelle, je
ne sais pas ce qu'il en est aujourd'hui). Comment mets-tu donc en
pratique les specs Posix dans un tel cas _sans_ passer par le noyau de
l'OS, ici, Windows ? Question subsidiaire : si Posix demande des choses
qui ne sont pas prévues par le noyau de l'OS hôte, comment fais-tu pour
les assurer proprement en userland (sans avoir un truc qui rame
excessivement, ce qui est le cas de Cygwin) ? Et des trucs imposés par
Posix et qui ne sont pas dans Windows, il y en a des tas.

Et ben t'as un truc qui rame et on s'en fout parce que ce n'est pas le
debat. On a meme un truc incomplet (mais tout le monde sait que Cygwin
n'implemente pas POSIX completement, tout comme les BSD d'ailleurs).

Le debat c'est que Cygwin n'est pas un emulateur POSIX parce que le
simple fait de dire qu'on "emule" POSIX ne veut strictement rien dire.
POSIX n'est pas un system hardware ou software et encore moins
l'assocation des deux.

Maintenant, écrire une couche d'émulation Posix sur mainframe, c'est

Mais il insiste le bougre.

Sans blaguer, comment tu fais pour refuser la simple definition des
mots alors que tu les as toi meme quote ?

Maintenant, réponds sur le fond si tu en est capable, ce dont je
doute fortement.

Euh, je m'obstine pas a vouloir "emuler" une norme ... moi !

On 16 juil, 09:34, Plumachau <plumac...@free.fr> wrote:

> de la daube en boîte tout ça, du gadget inexploitable ou qui ne se limite
> qu'à faire des machins basiques.. on est en 2009, j'ai envie d'exploi ter mon
> ordinateur et qu'il me serve dans pratiquement ce que je lui demande de
> faire, pas bricoler avec

Tu as beaucoup d'humour, c'est déjà ça.

Tu as envie d'exploiter ton ordinateur ? C'est pour ça que tu mets
Windows ?

Ben non il veut juste regarder le fond d'écran et le logo windows pour
méditer dessus ....

C'est beau de vouloir exploiter une machine avec un système qui le
ralenti tellement, qu'il faut une bête de course pour faire ... rien du
tout.

Si afficher un fond d'écran ...

Tu n'as pas envie de bricoler ? Pourtant c'est ce que tu fais ! Tu
installes un système instable et hyper buggé, ensuite il te faut un
antivirus, puis un antispy, puis un anti ...., etc.

Tant qu'il peut voir le fond d'écran, c'est pas grave ....

Ensuite, tu passes des heures à regarder ton indice de performance et a
essayer de gratter 1 point ou 2 ... je me marre !!!

En fait la seule raison pour laquelle les kroteux veulent une machine
qui boot vite, c'est juste parce que ce sont des gens stressés qui
veulent se ressourcer en méditant sur un fond d'écran et un logo ....

> mais c'est le pied linux bien sûrr

Tout est dit.

Le 22-07-2009, ? propos de
Re: Pour mettre tout le monde d'accord: Window9,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :

JKB wrote:

C'est plus fort que moi... Je te renvoie le compliment. Au fait,
j'attends la réponse à la question posée sur le fait qu'il est possible
d'écrire une implantation Posix en userland. Je te donne un indice.

Mais t'as rien compris au film toi.

Le probleme n'est pas d'ecrire dans le kernel, dans l'userland ou dans
un plateau de fromage. Le probleme est de repondre aux normes et
d'implementer les API, interfaces et logiciels.

Ca peut etre fait comme un gros porc dans une grosse libc toute pourrie,
de facon tres propre et tres decoupee avec les bonnes choses au bon
endroits, ca ne change rien que la finalite est d'implementer une norme
et de reussir une serie de tests qui garantissent une confirmite plus ou
moins reussie.

C'est toi qui est totalement à côté de la plaque. Je te repose la
question. Comment fais-tu pour implanter un truc qui nécessite d'être
dans le kernelland (pour par exemple des raisons d'atomicité comme les
sémaphores, les mutexes et j'en passe) en restant dans le userland dès
lors que le noyau de l'OS hôte ne possède pas le mécanisme (sinon, tu
n'aurais pas à l'émuler). En d'autres termes, le monsieur te demande par
exemple un bout de code C userland qui implante un mutex sans aucun
appel système.

Lorsque je contribuais à Cygwin, tous les programmes étaient
indépendants (comprendre, Cygwin n'était pas une machine virtuelle, je
ne sais pas ce qu'il en est aujourd'hui). Comment mets-tu donc en
pratique les specs Posix dans un tel cas _sans_ passer par le noyau de
l'OS, ici, Windows ? Question subsidiaire : si Posix demande des choses
qui ne sont pas prévues par le noyau de l'OS hôte, comment fais-tu pour
les assurer proprement en userland (sans avoir un truc qui rame
excessivement, ce qui est le cas de Cygwin) ? Et des trucs imposés par
Posix et qui ne sont pas dans Windows, il y en a des tas.

Et ben t'as un truc qui rame et on s'en fout parce que ce n'est pas le
debat. On a meme un truc incomplet (mais tout le monde sait que Cygwin
n'implemente pas POSIX completement, tout comme les BSD d'ailleurs).

Tout comme Linux.

Le debat c'est que Cygwin n'est pas un emulateur POSIX parce que le
simple fait de dire qu'on "emule" POSIX ne veut strictement rien dire.
POSIX n'est pas un system hardware ou software et encore moins
l'assocation des deux.

Maintenant, écrire une couche d'émulation Posix sur mainframe, c'est

Mais il insiste le bougre.

Sans blaguer, comment tu fais pour refuser la simple definition des
mots alors que tu les as toi meme quote ?

Maintenant, réponds sur le fond si tu en est capable, ce dont je
doute fortement.

Euh, je m'obstine pas a vouloir "emuler" une norme ... moi !

Non, tu t'obstines à répondre à côté de la plaque dans le plus pur
style tougardien (il manque d'ailleurs juste la référence à ton niveau
d'étude, d'ailleurs, ça m'étonne même que tu ne l'aies pas encore
rappelé). Je t'ai posé une question _PRÉCISE_, j'entends que tu me
donnes une réponse _PRÉCISE.

Tant que tu n'auras pas répondu à la _QUESTION_, tu continueras à
raconter tes conneries seul.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

JKB wrote:

C'est toi qui est totalement à côté de la plaque. Je te repose la
question. Comment fais-tu pour implanter un truc qui nécessite d'être
dans le kernelland (pour par exemple des raisons d'atomicité comme les
sémaphores, les mutexes et j'en passe) en restant dans le userland dès
lors que le noyau de l'OS hôte ne possède pas le mécanisme (sinon, tu
n'aurais pas à l'émuler). En d'autres termes, le monsieur te demande par
exemple un bout de code C userland qui implante un mutex sans aucun
appel système.

Mais on s'en tape de comment c'est fait. L'important est de savoir si
c'est fait.

POSIX ne dit pas qu'un Mutex doit etre dans le kernel ou ailleurs, il dit
quelle fonction doit etre presente, quels sont les arguments, ce qu'elle
retourne et comment elle doit reagir. Ensuite, tu l'implementes ou tu
veux. Et si tu ne peux le faire que dans le userland alors que ca serait
franchement mieux dans le kerneland, mais que c'est pas supporte ... ben
tu le fais dans le userland. Et si c'est pas possible du tout (comme ca
doit etre le cas pour de grosses portions de POSIX en ce qui concerne
Cygwin), ben tu l'implementes pas et ton implementation est incomplete.

Ca ne changera pas le fait que Windows NT 3.51 est POSIX.1
(raisonnablement) et que Cygwin est implementation (partielle) de la
norme POSIX sous Windows (a l'extreme limite, on peut le considerer
comme une emulation d'Unix ou de Linux).

Le 22-07-2009, ? propos de
Re: Pour mettre tout le monde d'accord: Window9,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :

JKB wrote:

C'est toi qui est totalement à côté de la plaque. Je te repose la
question. Comment fais-tu pour implanter un truc qui nécessite d'être
dans le kernelland (pour par exemple des raisons d'atomicité comme les
sémaphores, les mutexes et j'en passe) en restant dans le userland dès
lors que le noyau de l'OS hôte ne possède pas le mécanisme (sinon, tu
n'aurais pas à l'émuler). En d'autres termes, le monsieur te demande par
exemple un bout de code C userland qui implante un mutex sans aucun
appel système.

Mais on s'en tape de comment c'est fait. L'important est de savoir si
c'est fait.

C'est exactement le problème que tu ne veux/peux pas voir.

POSIX ne dit pas qu'un Mutex doit etre dans le kernel ou ailleurs, il dit
quelle fonction doit etre presente, quels sont les arguments, ce qu'elle
retourne et comment elle doit reagir. Ensuite, tu l'implementes ou tu
veux. Et si tu ne peux le faire que dans le userland alors que ca serait
franchement mieux dans le kerneland, mais que c'est pas supporte ... ben
tu le fais dans le userland. Et si c'est pas possible du tout (comme ca
doit etre le cas pour de grosses portions de POSIX en ce qui concerne
Cygwin), ben tu l'implementes pas et ton implementation est incomplete.

Tu ne comprends rien à rien et tu ne t'es _jamais_ posé la question
de savoir ce qu'est un mutex ni a fortiori une opération atomique (au
passage, si on savait faire ça en userland, ça simplifierait pas mal le
boulot des développeurs et ça éviterait aussi de se taper le
développement d'une libc sous Unix). Implanter de tels trucs en userland
pose un tas de problèmes, en particulier d'atomicité. Même en
kernelland, c'est difficile à faire (c'est pour cela que linuxthreads a
été abandonné au profit de NPTL car linuxthreads n'était en particulier
pas capable de rendre sem_post() async safe.). Retourne jouer aux billes.

Ca ne changera pas le fait que Windows NT 3.51 est POSIX.1
(raisonnablement)

On est pour une fois d'accord. Je rajouterais même très lacunaire.

et que Cygwin est implementation (partielle) de la
norme POSIX sous Windows (a l'extreme limite, on peut le considerer
comme une emulation d'Unix ou de Linux).

Ce n'est pas le débat et tu n'as toujours pas répondu à la question.
Je commence à croire que tu en es incapable.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.