oula… jeune fou,
ne les presse pas trop, il vienne a peine d’y mettre Xfree4.3( apeu pres )
:lol:
De toute façon kde-3.2 présente un nombre impressionnant de petits bugs très énervants. Il n’est pas encore assez mature pour être digne de debian. Pour ma part je trouve que gnome-2.5.90 (donc même pas rc) est déjà plus stable que la final de kde-3.2.
Voila! ce qui entre dans debian, même sid, est stable (au sens commum du terme.)
Xfree4.3 ne compilait même pas en -O2 sur certaines archi et avec certains versions de gcc : le responsable X de debian en est presque devenu fou…
Je recentre le topic 
2.6.4-rc1-mm2 > apparition d’une nouvelle option qui provient, je pense, de la branche WLI:
[cpp]Use 4Kb for kernel stacks instead of 8Kb (4KSTACKS) [N/y/?] (NEW) ?
If you say Y here the kernel will use a 4Kb stacksize for the
kernel stack attached to each process/thread. This facilitates
running more threads on a system and also reduces the pressure
on the VM subsystem for higher order allocations. This option
will also use IRQ stacks to compensate for the reduced stackspace.[/cpp]
Il se pourrait que cette option soit de la pure balle pour les petits pcs servant de routeur/firewall/passerelle
Cette nouvelle option se trouve dans “kernel hacking”
Attention: cette option n’est pas compatible avec les drivers proprio nvidia (ecran noir, hard freeze)
“le responsable X de debian en est presque devenu fou…”
lol
sT0ne: très intéressant en effet pour les routeurs/passerelles.
Ca va casser pas mal de drivers binaires mais ceux qui utiliseront cette option s’en fiche.
“le responsable X de debian en est presque devenu fou…” : Ce n’est pas le sujet mais je te jure qu’il n’était pas content du tout du tout.
heum, sur ma 2.6.3, au bout, il me dis que le DMA n’est pas activé, et je pense que cest effectivement le cas parce que le chargement est super long!
Je comprends pas, je pense avoir activé tout se qui fallais…
Verifies que l’option est bien coché dans make menuconfig. Verifie que tu a selectionné le bon matos dans cette section.
Sans dma, c’est sur que ça doit être long.
J’attaque la partie Loadbalancing.
Le design de l’architecture est en cours de stabilisation. Je “négocie” aussi avec l’Université du Michigan (Ce sont eux qui s’occupent de l’implem linux).
Si il y a des amateurs, le projet débute, c’est le moment ou jamais de participer. J’aurai mon site comunautaire d’ici peu. vous l’avez en avant première sur OSA.
Edit:
- pour le moment on ne touchera pas “trop” au noyau.
- on s’appuie sur IPv6, donc il faudra activer l’encapsulation IPv6 over IPv4.
j’aurais de plus amples connaissances en programmation réseau ce serait avec joie 
mais là c’est trop short 
“the kernel will use a 4Kb stacksize for the kernel stack attached to each process/thread.”
C’est quoi la pile d’un processus ? C’est la mémoire attachée a chaque processus ? :??:
Si oui 4kb ca me parait quand meme pas beaucoup :ouch:
val> c’est une partie de la mémoire utilisée par un processus
un processus utilise 3 segments de mémoire : un segment pour le code, un segment pour la pile (stack) et un segment pour le tas (heap)
Euh il manque un, non ?
La pile, c’est les adresses retour des fonctions, c’est ca ?
Le tas, c’est la ou on alloue les variables ?
Le segment ?
le mysterieux dernier ?
Merci :jap:
Tanenbaum parle de 4 éléments par thread:
-compteur ordinal
-registres
-pile
-état
le mystérieux dernier serait son état (en cours d’exécution, bloqué, prêt ou arrêté)
non faute de frappe
il en utilise bien 3
la pile c’est les variables allouées sur la pile, donc en gros : les variables allouées sans allocation de mémoire en C et consors (-> la variable est retirée de la pile à la sortie de son bloc de définition), les variables passées en paramétres aux fonctions, les variables de retour des fonction
le tas regroupe les variables allouées par une allocation dynamique (utilisation de malloc en C, new en C++/Java/C#…)
pour désallouer une variable allouée sur le tas, il faut le demander explicatement (utilisation de la fct free en C, opérateur delete en C++) sauf si le langage posséde un garbage collector (java, c#, etc.)
Ok merci
l’état est à mon avis stocké dans les tables de processus du noyau
le compteur ordinal est un registre du proc spécifique, stocké d’ailleurs aussi dans la table des proc du noyau lors de l’excution d’un processus tier
oui je pensais qu’il était question de la table des processus alors que, si j’ai bien compris, on parle en fait de l’allocation mémoire.
jojolapin> tu pourrais expliquer :“This option
will also use IRQ stacks to compensate for the reduced stackspace.”, stp.
ce serait avec plaisir, mais je ne sais pas trop ce que sont les IRQ stacks
libre interprétation -> le noyau utilise peut être une pile pour gérer les IRQ, et cette option réduirait cette pile (d’où le pb avec certains drivers) et le noyau stockerait ainsi une partie de la pile du proc actif dans cet espace libre
mais ça n’est qu’une idée qui me vient à l’esprit là