Raphael Junqueira a écrit 337 commentaires

en fait pour le rendre persistant fo modifier le fichier de conf
/etc/sysconfig/harddisks (config generique des disques) ou bien creer une conf specifique par disque via les fichiers /etc/sysconfig/harddiskhda, /etc/sysconfig/hardiskhdb, ...

voilou j'espere que ca ira mieux

de rien :)

ntpl est surtout côté glibc. Et la glibc 2.3 marche très bien avec 2.4 et 2.5 sur mon système. Merci.

On est d'accord mais tout cela se base sur certaines primitives du kernel 2.5 qui n'existent pas sur le 2.4 donc le comportement n'est pas le meme.

Humm. Tu as un lien ?

man pthread_create

Tu es sûre ? Linux a eu du mal pour avoir une implémentation 100 % Posix.

s/sure/sur

Ils ont surtout galere car linux, en bon unix comme il se doit, ne savait gerer que des processus et non des threads (qui peuvent etre englobees dans un contexte de processus) actuellement ca n'est tjs pas le cas mais le kernel 2.4 fourni l'appel clone pour avoir un processus allege.

Tu as testé avec LD_ASSUME_KERNEL ... Vi c'est ce que je fait quand je peut le faire, mais dans certains cas d'utilisation je ne peut faire le LD_ASSUME (marre) :( http://people.redhat.com/drepper/ Je connaissait mais c'est pas tres clair. Petit rappel. NTPL est posix et linux-thread est posix aussi. Les problèmes que "révèlent" NTPL, sont les usages non posix de linux-thread. C'est comme pour les montées en version de gcc. Cf mon commentaire plus haut

La première beta de la rh9 avait ntpl. Et l'annonce signalait aussi ntpl Le probleme etant que des devs n'utilisent pas (ou ne devraient pas utiliser) des distribs betas. Mais c vrai que pour wine depuis la sortie de la beta de RH ils travaillaient dessus. Pour la "maturité", ça fait depuis 6 mois au minimum que ntpl est dans 2.5 et le cvs de glibc. Oki mais la version 2.4 n'est pas exactement la meme. Le problème de wine, jre, realplay, etc... est qu'ils font un usage non posix des threads. Ca j'en suis bien conscient, mais si on pouvait simplement suspendre les taches a volonte (ce que ne permet tjs pas les NTPL) ca resolverait bcp de ces probs d'utilisation crade. Il faut que les applis s'adaptent pour faire une code 100 % posix. Elles peuvent vraiment pas car la norme posix pour les threads est trop limitee (d'ou les NGPT de'IBM)

Ah ? Toi aussi tu utilises Debian ? Non les vrais ils recompilent too :) comme ca c des la compile que ca passe pas apres la nouvelle glibc :)

P.S. veuillez m'excuser si je m'emporte sur ce coup là ... mais ça fait du bien ;) va y je t'en prie, moi j'en veut aussi a mdk d'avoir aussi mit la glibc 2.3.2 sur cooker, depuis les applis que j'utilise le plus souvent sous nux sont mortes :(((((((((( P.S.2 a moins que quelqu'un ait une solution pour faire fonctionner Wine avec leur glibc-2.3.2 ??? Un develloppement a ete fait pour le support des NTPL. Tu peut donc recup la version cvs de wine: #cvs -:pserver:cvs@cvs.winehq.com:/home/wine login passwd: cvs #cvs -z 3 co wine puis tu configure avec l'option: #./configure --with-nptl et voilaa plus qu'a compiler et installer (cf README) Bon c du beta et c pas garanti que ca marche partout (chez moi ca chie bien) vu que personne ne savait trop comment ca marche les NTPL (merci RH).

holala, ya ntpl, ça va crasher de partout, je reste avec ma mdk. ca c'est tres con, surtout si tu utilise cooker et que tu upgrade ta glibc :) J'ai envie de faire une descente avec une hache car ca fait plus d'un semaine que mon wine marche plus.

sudo hdparm -i /dev/hd* ? j'ai eut un probleme similaire, un de mes disques se trouvait avec l'UDMA desactivee (pas compris pkoi)

Ben mandrake a aussi sorti un truc pas très testé comme redhat le fait avec ntpl. Si je me rappelle bien, l'ACPI n'a ete integre que tardivement par mdk. De plus les gros problemes ACPI sont surtout present sur des bonnes machines avec du matos industriels (style RAID, etc...) ce que ne vise pas mdk (sauf la distrib serveur qui elle n'a pas l'ACPI) Ce qui me gonffre, c'est que lorsque RedHat sort un truc, systèmatiquement ya les critiques qui fusent : - pas fiable - pas compatible - etc... Ca depend du contexte, le fait de porter la NTPL sur le 2.4 pkoi pas, le fait de faire le forcing passe encore, maintenant le fait de l'integrer sans trop tester (et c'est le cas vu la maturite du portage) et sans chercher a "prevenir/aider" des projets importants du LL qui en subiront les consequencs... Mandrake innove aussi (et c'est très bien) et n'a jamais de critique. Et moi ça commence à me brouter sérieusement. J'ai rien contre Mandrake. C'est cette différence de traitement qui est trollesque, puante qui me les casse. Ben si on critique, mais dernierement mdk c'est bien calme (bon si ils pouvaient faire qu'un jour automount marche ca serait bien) La prochaine Mandrake (avec linux 2.4) aura surement NTPL et je suis sûr qu'il n'y aura pas la moindre critique. Elle l'a deja (cf cooker) maintenant ils testent sur cooker. NTPL EST le nouveau standard pour les thread. RedHat pousse, aide son adoption et c'est très bien. Ca n'est PAS un standard c'est une implementation du standard posix (comme peut l'etre les LinuxThreads) Et justement en parlant de standard les NGPT (New Generation Posix Thread) sont justement l'implementation des idees d'IBM a innover le standard posix vieillissant (en ayant par example le moyen de suspendre une thread)

C'est se foutre de la gueule des devs Linux ce type de propos. Les devs Linux on choisi NTPL pour Linux 2.6. Ils sont grands et pas facilement impressionnables. Féliciano tu demarre au quart de tour :) Plus serieusement les deux "implementations" se valent et sont theoriquement capable de tirer le maximum du nouveau noyeau. Maintenant pour ta culture, le probleme etant qu'il faut en choisir une car la majorite du code specifique se situe "dans la libc" (le kernel ne fait rien de bien special, les patches kernels peuvent etre les memes pour les deux implementations car ne font que rendre dispo a la libc des primitives noyeau). Et bien sur ca fait pas tres propre que la libc ait deux implementations. RedHat en sortant RH9 avec NTPL, va aider sont adoption et le fiabiliser. Le probleme c'est qu'ils ont fait le forcing sans avoir pris la peine d'aider les projets qui subissent actuellement le changement (je parle principalement de wine et valgrind) tout en sachant que peu de gens savent reelement comment fonctionne les NTPL en interne (ce qu'a besoin de savoir les deux projets sus-cites). Pour la fiablisation je pense que c une bonne chose, mais fiabiliser une gros changement comme cela sur une version de distrib theoriquement stable par le clients ... je n'approuve clairement pas du tout !! C'est tout benéfice pour Linux 2.6. G des doutes sachant que la partie libc (la plus critique, celle a fiabilisee) ne sera pas exactement la meme pour les deux noyaux. Faut aussi remarquer qu'Alan Cox a développé le nouveau code IDE (initialement pour 2.6) avec le 2.4 et que tout le monde l'utilise et personne ne se plaind. C'a un peu rien a voir, et surtout qu'ils l'ont bien tester sur une longue periode avant de le mettre dans le noyau stable (la ils ont pas voulus prendre de risques avec les clients)

Non, certainement pas tout faux. Mais je vois pas trop l'intêret de sortir ce genre de chose (NPTL)

Pour nous c clair, Pour RH y en a pleins:
- etre la distrib la "plus rapide"
- chercher a imposer la NTPL par rapport aux NGPT (sponsorise plutot par IBM)
- vendre plus de support :)

1) C'est la NGPT qui sera dans le 2.6 (ou le 3.0), donc incompatiblité entre la RH9 et les versions futures (en théorie, non, mais la pratique sera certainement autre chose)

Les incompatibilites seront encore pour les memes applis qui ont mal supporte le passage LinuxThreads vers NPTL (les devs wine et valgrind vont surement aimer le support de 3 types de threading different)

2) La NGPT sur un 2.4 fait quand même office de grosse verrue par rapport au support des threads actuels (qui est ce qu'il est, mais qui fonctionne)

Enfin pout moi c un peu equivalent a l'ancien principe, mais c vrai que les LinuxThreads marchotteront surement mieux sur un 2.4 que la NGPT

3) Etant un patch sur le 2.4, bonjour les incompatibilités.

C surtout pour la glibc que ca m'inquiete.

Ben je voit pas trop comment il aurait pu tester l'integration NPTL sachant que c inclus dans la libc. A part si il aurait fait un developpement specifique pour tester (et ca n'aurait interresser que les developpeurs).
Du cote user, ca ce voit pas mis a part un peu plus de "fluidite" des applis multithreadees et le fait que valgrind, wine et qques autres applis sensibles fonctionnent assez mal.

ben essaye de jouer avec les threads sous linux tu va voir que c tres facile alors d'eavori une appli "mal concue" :p

Autant pour moi, tu as raison

J'ai du faire trop de threading sur SUN dernierement au point de me melanger un peu les pinceaux.
Enfin au final, ca change pas que les LinuxThreads c de la m... et dire que j'en ai passer des journees a me battre avec pour avoir des applis qui deadlock pas, sniff ca va me faire un choc de plus galerer comme ca.

un truc comme ca, ca devrait aller :)

#if defined(DEBUG) && defined(HAVE_VALGRIND_MEMCHECK_H)
# include <valgrind/memcheck.h>
# define VG_MARK_INACCESSIBLE(p,l) VALGRIND_DISCARD( VALGRIND_MAKE_NOACCESS( (p), (l) ) )
# define VG_MARK_UNINITIALIZED(p,l) VALGRIND_DISCARD( VALGRIND_MAKE_WRITABLE( (p), (l) ) )
#else /* VALGRIND */
# define VG_ MARK_INACCESSIBLE(p,l)
# define VG_MARK_UNINITIALIZED(p,l)
#endif /* VALGRIND */

Valgrind ne détecte pas tout (tu peux écraser les variables de la pile comme bon te semble) mais il détecte beaucoup.

En fait pour les variable que tu compte surveiller "sur la pile" valgrind exporte des nombreuses et jolies macros pour ca (et bien d'autres choses cf <valgrind/memcheck.h>).

C'etait un abus de langage en fait
les LinuxThreads n'ont pas un mapping 1:1 par rapport aux threads kernel mais plutot n:p. C'est donc a la charge d'un ordenanceur en user mode (afin de decider qu'elle threads "posix" vont sur quel pool gere par une thread kernel) que ce gere les linuxthreads.
En jouant avec les options tu peut simuler une comportement 1:1, mais sachant que le kernel n'a pas trop notion de ce que tu trafique (sinon que tu a utilise clone comme un warrior) il gere ca comme une mer...

Petite precisions:

En fait la NPTL est compatible de facon binaire et source avec les anciennes threads (les LinuxThreads) c'est juste la methode de fonctionnement interne (des threads kernel au lieu de threads users pour l'ancienne) qui differe.
Le probleme vient que certaines applis faisant du tres bas niveau avec les threads (wine, valgrind, ...) ne fonctionnent plus tres bien car se basaient sur l'ancien comportement (et surtout le fait que les threads etaient gerees en user mode).

Moi je suis tout a fait d'accord que la lib NPTL est la voie a suivre (surtout que les LinuxThreads c'etait plus un vieux hack qu'autre chose) maintenant, le fait de l'imposer comme ca dans une distrib grand publique alors que des logiciels importants impactes ne savaient toujours pas comment s'integrer, je pense que ca n'est vraiment pas une terrible idee.

D'ailleurs au niveau de wine, malgre le fait qu'ils ont bien bosse dessus il y a encore de nombreux problemes.

tiens g d'ailleurs surtout oublie celui-la (g honte surtout que je l'utilise tous les jours):
http://kcachegrind.sourceforge.net/(...)

un des rares outils qui facilite le developement industriel sous unix.

Ajout:
il y a aussi un tres bon plugin d'integration de valgrind dans la version cvs de kdevelop (gideon):
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdevelop/parts/valgrind/(...)

a mon avis il ne gere par la branche 1.9.x de valgrind mais ca ne saurait tarder.

vi le bonheur, que du bon souvenir ;)

et dans la foulee faudrait aussi Microprose F1 GP, avec ca les trois seuls jeux qui m'on reelement accroche seront sous linux ;))

ca je savait,
d'ailleurs ils etaient pas chaud pour garder la imlib1 juste pour une appli de kdegraphics (l'appli qui l'utilise je croit que c'est quickshow).

Mais c vrai que ca aiderait bien kdefx si on se basait dessus, le probleme etant de savoir ce que ca va donner sur les unix non-GLX

ca na rien a voir avec le wm, ca n'utilise que Qt (et kdefx).
tu peut utiliser kicker avec wm si tu veux (a condition d'avoir la version avec le support minimal des standards net)

pas con du tout l'idee de l'opengl :)

tu me fait meme penser que la imlib2 possede tout ca sous la main, mais bon ca m'etonnerait qu'ils apprecient que kdefx depende de la imlib :(
J'essayerait ce we.

Sinon g des doutes que l'openGL lise le svg (ptet que via rsvg dans le nouvel xfree mais g des doutes) mais en utilisant ksvg on peut recuperer suffisement de niveau pixmaps pour l'effet (c ce que je faisait)