L'architecture de bus InfiniBand est prise en charge dans ce nouveau noyau : c'est apparemment une alternative au bus PCI où les données sont transmises en série et en multiplexage, au lieu d'être transmises en parallèle, ceci ne concernant pour l'instant que les serveurs « high-end » et certains PC.
Aller plus loin
- Le noyau linux (10 clics)
- InfiniBand (4 clics)
- L'email d'annonce (4 clics)
- 2.6.11 sur kernaltrap (11 clics)
- ChangeLog (2 clics)
# whaouh! j ai hate d essayer çà !!
Posté par zobinart . Évalué à 6.
avec mon ibm t42, lire cette phrase :
"Ce noyau apporte une grande liste de mises à jour : pilotes ACPI, [..]"
c'est que du bonheur, non pas que l'ACPI ne focntionnait pas jusqu'à présent, non, juste que peut être le déréglage de l'horloge et l usb qui saute en retour de suspend auront peut etre disparus...
allez, bon "make menuconfig" à tous !
[^] # Re: whaouh! j ai hate d essayer çà !!
Posté par Stephane . Évalué à 4.
je suis un peu las de devoir décharger tous les modules usb avant de partir en suspend ou en hibernation (sans assurance d'ailleurs que ça refonctionnera au resume).
/me's going to pray...
[^] # testé ok sur un laptop AmiloA
Posté par rzr (site web personnel) . Évalué à 5.
le "double tap" ne marche plus comme click gauche, mais y a un param de boot peut etre : mousedev.tap_time
sinon des patchsets sympatoches a l'horizon pour le 2.6.11 ?
A suivre...
gpg:0x467094BC
[^] # Re: testé ok sur un laptop AmiloA
Posté par asbin . Évalué à 2.
Moi je patch toujours mon kernel avec le cko (Con Kolivas patchset based overloaded kernel), voir ici : http://kem.p.lodz.pl/~peter/cko/(...)
C'est une suite sympathique, avec des mises à jour de alsa, acpi, bttv, avec fbsplash et vesafb-ng, avec le Software Suspend 2, reiser4 et supermount, ainsi que les patchs d'Alan Cox (les -ac) ... bref, que du bonheur !
;-]
# Il manque
Posté par Christophe Lucas (site web personnel) . Évalué à 10.
Voilà, mes deux cents ;-) et je => []
[^] # Re: Il manque
Posté par fabb . Évalué à 10.
Four-level page tables :
http://lwn.net/Articles/117749/(...)
Optimisation d'ext3 :
http://lwn.net/Articles/112566/(...)
Circular pipes (très interessant) :
http://lwn.net/Articles/118750/(...)
Big Kernel Semaphore :
http://lwn.net/Articles/102253/(...)
Merci à lwn pour ces excellents articles.
[^] # Re: Il manque
Posté par mdlh . Évalué à 4.
Je serais beaucoup plus heureux lorsque cela integrera le support de taille de page variable.
[^] # Re: Il manque
Posté par fabb . Évalué à 0.
Les autres cpu 64bit suivront.
> Je serais beaucoup plus heureux lorsque cela integrera le support de taille de page variable.
???
à chaud ou via une recompilation du noyau ?
Pourquoi faire ?
[^] # Re: Il manque
Posté par mdlh . Évalué à 3.
C'est mis au conditionel pour l'instant. Mais je ne faisais que dire que ce n'etait pas pour tous "aujourd'hui". Rien d'autre.
à chaud ou via une recompilation du noyau ?
Via recompilation noyau on sait deja faire. La gestion de taille de page variable est "live". En fait le gestionnaire choisit, par les fait, la taille de la page. Il peut decider de decomposer une grande page en plusieur, ou de le recomposer des plus petites en plus grandes.
La granularite se fait a la page elle-meme. Une meme application peut avoir plusieurs tailles de page.
Pourquoi faire ?
J'ai pas envie de rentrer dans la theorie. En gros, certaines applications fonctionnent mieux avec des pages plus grandes, d'autres fonctionnent mieux avec des pages plus petite. Aujourd'hui, pour les architectures qui supportent plusieurs taillent, tu imposes, a la compilation du noyau, une taille fixe pour tout le monde. Donc tu favorises une application par rapport a une autre. Le support de la gestion de page variables permet de:
- avoir la taille correcte pour chaque applications/zone de donnees
- Ne plus avoir a se poser la question lors de la compilation
Dans les deux cas, le Kernel s'occupe de tout.
[^] # Re: Il manque
Posté par fabb . Évalué à 2.
Je ne suis pas convaincu que toutes les applis marchent après avoir changé PAGE_SIZE (qui est une macro définie dans /usr/include/asm/page.h).
> En gros, certaines applications fonctionnent mieux avec des pages plus grandes, d'autres fonctionnent mieux avec des pages plus petite.
Je dis pas non mais t'aurais un exemple concret ou un bench je te plusserais :-)
Puis c'est peut-être plus pertinent de faire ça côté libc si tu penses à l'optimisation de malloc/free. Un malloc n'aboutis pas systématique a un appel système "malloc" et beaucoup d'appels systèmes peuvent marcher sur une page mémoire (read, write, brk, etc).
Au feeling, je n'ai pas l'impression que ça peut apporter un gain important.
[^] # Re: Il manque
Posté par galactikboulay . Évalué à 2.
Normalement une application ne doit pas se préoccuper de PAGE_SIZE ou de tout autre particularité de la mémoire virtuelle.
Au feeling, je n'ai pas l'impression que ça peut apporter un gain important.
Pour faire les conversions adresse mémoire virtuelle -> adresse physique, le processeur utilise un cache TLB (Translation Lookaside Buffer). A priori, je dirais que plus la taille des pages est grande, plus on peut stocker d'associations (adresse virtuelle, adresse physique) dans cette table. Mais je me trompe peut-être.
[^] # Re: Il manque
Posté par Christophe Fergeau . Évalué à 2.
Les man de mmap et mlock ne sont pas d'accord avec toi... Ok, la taille de page dont ils parlent ne correspond pas nécessairement à la taille de page réelle utilisée par le noyau, mais à mon avis à l'heure actuelle c'est le cas.
[^] # Re: Il manque
Posté par galactikboulay . Évalué à 1.
Quoiqu'il en soit, tant que tu respectes la contrainte imposée (offset multiple de PAGESIZE ou autre), tu te moques complètement de comment est réalisée l'implémentation derrière, et des particularités du CPU et de sa MMU. C'était le sens de mon message :)
[^] # Re: Il manque
Posté par Christophe Lucas (site web personnel) . Évalué à 1.
D'ailleurs au passage, le code gérant le TLB sur architecture PPC a été revu.
Bonne journée les gens...
[^] # Re: Il manque
Posté par galactikboulay . Évalué à -1.
"le processeur utilise un cache TLB"
[^] # Re: Il manque
Posté par Christophe Lucas (site web personnel) . Évalué à 3.
J'ai bien compris merci et je sais très bien ce qu'est un cache TLB. Maintenant, si préciser réellement ce qui fait une traduction d'adresses virtuelles en adresses physiques est un crime, j'aurais peut-être dû me taire !
La phrase d'origine laissait penser que c'est le cache TLB qui fait cette traduction, je voulais juste souligner cela.
Bon bah je retourne apprendre à lire et => [].
[^] # Re: Il manque
Posté par reno . Évalué à 1.
Comme dit plus haut une gestion par le noyeau de taille de page variable permettrait une meilleure utilisation du TLB, qui en général n'est pas bien gros..
J'ajouterai que le noyeau gère des listes qui décrivent l'utilisation des pages, avec les taille mémoires actuelles et des pages de 4k, la taille de ces structures est assez importantes..
Une gestion des pages avec une taille variable permettrait probablement de réduire la taille occupées par ces listes.
Le gain en performance se faisant problablement sentir sur les configurations avec beaucoup de mémoire.
[^] # Re: Il manque
Posté par zeSixty4Douille . Évalué à -8.
[^] # Re: Il manque
Posté par zeSixty4Douille . Évalué à -5.
Quand au gains, j'ai vu certains scenario passer 50 % de leurs temps a convertir des adresses physiques en adresse virtuel en 32-bit (dependant de l'archi).
Je trouve desolant qu'actuellement, Linus passe plus de temps a faire des fixes pour les portable IBM qu'a developper serieusement. Les mecs de Debian et de Fedora devrait lui lacher la grappe.
Je trouve desolant aussi que l'on parle ENCORE de l'ACPI.
J'aime pas IBM.
[^] # Re: Il manque
Posté par mdlh . Évalué à 6.
Je pense au fait qu'aujourd'hui, sur certaine machines, le cache est trop gros pour avoir une complete couverture par la TLB (lire dans le document de mon second lien).
Par "couverture", je parle de la traduction Memoire Virtuelle => Memoire Physique.
Augmenter la taille des pages etend la couverture de la TLB, et donc limite le nombre de Page Fault (zone virtuelle non decrite dans la TLB, ce qui necessite une serie d'acces en memoire, tres couteuse, permettant de trouver la description, si elle existe, Memoire Virtuelle => Memoire Physique.
Mais, augmenter la taille des pages peut etre a l'origine de gachis. Il suffit de penser a la taille de bloc dans les systemes de fichier. Plus c'est gros, plus tu as de chance de "perdre" de la memoire. Si une application n'a besoin que de 2Ko, tu perds moins de memoire en allouant 4ko au lieu de 16ko par exemple.
Quand je parle d'allocation, c'est pas malloc/free, mais dans la VM.
Bon quelques liens:
http://www.gelato.unsw.edu.au/IA64wiki/NPTLbenchmarks(...)
C'est plutot un bench qui a ete fait lors de l'implementation des NPTL. Mais par contre il montre l'influence de la taille d'une page.
http://www.cs.rice.edu/~ssiyer/r/superpages/(...)
Un document expliquant la problematique surement mieux que moi et une possible mise en oeuvre (pour FreeBSD).
[^] # Re: Il manque
Posté par fabb . Évalué à 1.
Au niveau hardware/cpu, je n'y connais pas grand chose :-)
Merci pour tes précisions.
[^] # Re: Il manque
Posté par Brice Goglin . Évalué à 4.
> limite le nombre de Page Fault (zone virtuelle non decrite dans la
> TLB, ce qui necessite une serie d'acces en memoire, tres couteuse,
> permettant de trouver la description, si elle existe, Memoire Virtuelle > => Memoire Physique.
Non, un Page Fault, c'est quand la _page_ n'est pas présente en mémoire physique, c'est-à-dire quand elle a été swappée sur le disque.
Quand le traduction virtuelle=>physique n'est pas dans la TLB, c'est un Cache Miss comme dans n'importe quel cache, un TLB miss ici.
Un TLB Miss, c'est plusieurs accès mémoire donc c'est lent.
Un page fault, c'est un accès disque donc TRES TRES lent.
[^] # Re: Il manque
Posté par Brice Goglin . Évalué à 4.
> qu'ettendre la taille memoire physique supporte.
>
> Les autres cpu 64bit suivront.
Non, ca n'a rien a voir avec le fait d'etre une architecture 32 ou 64 bits. Ca ne depend que du nombre de niveaux de table de pages supportés par le matériel.
Les processeurs intel en supportent 2 ou 3. Les anciennes archis 64bits generalement 3. L'Opteron d'AMD en supporte 4.
Le noyau a donc du passer en 4 niveaux logiciels pour utiliser la capacité des opterons au maximum.
Sur les autres architectures, on rend 1 ou 2 des 4 niveaux logiciels pipo pour n'utiliser que les 2 ou 3 niveaux materiels.
Ensuite, on choisit la taille de chaque niveau et de la page, en général autour de 10 car c'est un bon rapport performance/cout.
Par exemple, Linux sur Opteron choisit 12 bits pour les pages (4ko) et 9bits pour chacun des 4 niveaux. Cela donne 48bits d'adresse physique supportés (contre 39 avant si je ne m'abuse).
On peut donc utiliser 256To de RAM physique.
Par contre la mémoire virtuelle des processus est limitée à 40bits (1To).
[^] # Re: Il manque
Posté par fabb . Évalué à 2.
Ce n'est pas tout à fait ça si j'ai bien compris. Sur amd64 il y a deux espaces mémoires (parmis d'autres) :
- espace utilisateur
- espace physique
2^35 bits de page pour la mémoire virtuelle et 2^40 bits pour la mémoire physique selon les specs.
Avec page = 2^12.
Espace utilisateur est de 47 bits (128To). C'est les spec du cpu qui limite. Linux utilise tout.
Espace physique est de 52 bits (4096To) pour les spec. C'est 46 bits(64To) pour l'implémentation Linux. Les cpu actuels ne dépassent pas 40 bits (1To).
http://www.x86-64.org/lists/discuss/msg06059.html(...)
> Par contre la mémoire virtuelle des processus est limitée à 40bits (1To).
128To si j'ai bien compris.
mémoire virtuelle peut-être supérieur à mémoire physique car il y a le swap et mmap.
[^] # Re: Il manque
Posté par Brice Goglin . Évalué à 1.
> mémoire physique selon les specs.
>
> Avec page = 2^12.
> Espace utilisateur est de 47 bits (128To). C'est les spec du cpu
> qui limite. Linux utilise tout.
Ah oui en effet, c'est 47 et pas 48 bits d'adresse physique.
Voir dans include/asm-x86_64/pgtable.h :
et http://lwn.net/Articles/116954/(...)
Apparemment, les AMD64 supportent moins que sur les Opterons.
> > Par contre la mémoire virtuelle des processus est limitée à
> > 40bits (1To).
>
> 128To si j'ai bien compris.
> mémoire virtuelle peut-être supérieur à mémoire physique car il y a > le swap et mmap.
La mémoire virtuelle peut avoir une taille quelconque indépendante de la quantité de mémoire physique (128To ici puisque 47bits).
Le système peut limiter la mémoire virtuelle à la taille qu'il veut.
Linux a finalement choisit de limiter également à 47bits, en effet.
(cf TASK_SIZE dans include/asm-x86_64/processor.h)
[^] # Re: Il manque
Posté par fabb . Évalué à 1.
Je n'ai pas pensé qu'il puisse être différent sur ce point :-)
> Linux a finalement choisit de limiter également à 47bits, en effet.
> (cf TASK_SIZE dans include/asm-x86_64/processor.h)
Je n'y connais pas grand chose mais ce n'est pas ce que je vois.
Il me semble que c'est une limite du cpu qui se retrouve dans processor.h (voir pgtable.h que tu as pointé, 4 "indirections" de 9 bits (512 slots)). Ce qui est normal, Linux n'a pas à tenter d'accéder à un espace mémoire que le cpu ne peut de toute façon pas atteindre. N'oublions pas que page_size = 2^12. Si page_size > 2^12 on peut repousser cette limite.
Selon ce que je comprend, Linux "subit" le fait que le cpu ne peut utiliser que 2^35*page_size pour les adresses virtuelles. (D'accord, c'est 2^36 (2^(9*4)) mais je ne sais pas où j'ai perdu un bit :-)).
Là où Linux limite, c'est pour l'espace physique qui peut monter à 2^52 et Linux limite à 2^46 (pour des raisons que je n'ai pas compris). Mais ce n'est pas grave car actuellement le maximum disponible ("à l'achat") est 2^40.
[^] # Re: Il manque
Posté par fabb . Évalué à 1.
Finalement j'ai compris. C'est 2^36*2^12 (2^48) pour tous l'asdressage mémoire mais il est divisé en deux :
- mémoire virtuel : 2^47
- mémoire noyau : 2^47
> Là où Linux limite, c'est pour l'espace physique qui peut monter à 2^52 et Linux limite à 2^46 (pour des raisons que je n'ai pas compris).
Non, Linux ne limite pas.
Puisque page_size fait 2^12, il y a 2^47 pour le mode noyau (comme pour la mémoire virtuelle) et dans ce 2^47 on garde la moitier (2^46) pour la mappage vers les adresses physiques.
Finalement, j'ai beaucoup appris :-)
Ce qui limite l'espace adressable par Linux, c'est le choix fait par Linux d'utiliser page_size=4096 comme pour x86 afin de pouvoir exécuter aussi des applis x86 (qui ont page_size=4096) et éviter d'inutile problème de compatibilité.
Mais augmenter page_size c'est aussi bouffer plus de mémoire.
Rien de dramatique dans le "page_size=4096" car on est déjà bien au delà des limites du hardware disponible. Pour un espace mémoire maxi avec amd64 et selon ses specs (mémoire physique limité à 2^52) il faudrait page_size=2^18 soit 256 ko (!). On aurait :
- mémoire virtuelle : 8192 To
- mémoire physique : 4096 To
Y a du gras.
[^] # Re: Il manque
Posté par David Decotigny (site web personnel) . Évalué à 7.
N'empeche il serait temps que linux definisse une API de gestion de la VM qui se detache un peu des details de la MMU du x86. C'est pas pour dire, mais sur d'autres archi, la MMU ne travaille pas du tout avec des tables de traduction "directes" comme dans le cas x86 (je pense a ppc). Mieux vaudrait avoir une API bien plus propre, bien plus simple et bien plus portable que celle qui consiste a emuler les X niveaux d'indirection de la MMU x86.
Voila, c'etait mes 3 cents de mauvaise humeur... Troll en perspective ?
[^] # Re: Il manque
Posté par fabb . Évalué à 1.
C'est le role du noyau d'être au plus près du hardware pour être le plus rapide possible.
Ce qu'il faut c'est que les drivers, applis soient portables. C'est le cas.
Dans un noyau il y a toujours des parties qui sont spécifiques au hardware.
[^] # Re: Il manque
Posté par borntoulouse . Évalué à 1.
La conception actuelle en 3 niveaux d'indirection fait référence au x86, alors que sur d'autres archi, on peut avoir 1 ou 2 niveau, voire un fonctionnement différent.
D'ailleurs, je ne sais pas comment ca se passe sur la MMU du PPC...
Linux a quand même été conçu initialement pour tourner sur un x86, mono-proc, etc, etc. Et ca se sent.... même dans la ligne 2.6 !
[^] # Re: Il manque
Posté par fabb . Évalué à 1.
Oui mais c'est impossible.
> et permettant cependant d'utiliser des optimisations pour une implémentation d'une cible particulière.
Optimization qui ne concerne qu'une partie du noyau. Les drivers ignorent cette optimisation dans la majorité des cas et ne vois que "bête" adresse.
> Linux a quand même été conçu initialement pour tourner sur un x86, mono-proc, etc, etc. Et ca se sent.... même dans la ligne 2.6 !
Linux tient compte du réel. Si le cpu a besoin x niveaux pour l'exploité, Linux n'a d'autre choix que de les implémenter. Si tu ne les utilises pas (entre autre pour distinguer mémoire virtuelle et physique) autant retourner sous DOS.
[^] # Re: Il manque
Posté par David Decotigny (site web personnel) . Évalué à 2.
Chouette, un troll pour techos !
>> c'est qu'un noyau qui se veut conçu pour être portable devrait être indépendant d'un quelconque modèle d'architecture réelle spécifique
Linux ne se voulait pas portable a ses debuts, c'est d'ailleurs sans doute pour ca qu'on a cette API foireuse au niveau de la gestion de la MMU.
> Oui mais c'est impossible.
Oh, allez, ne soyons pas defaitiste comme ça ! Allons, reprenons-nous ;)
> Optimization qui ne concerne qu'une partie du noyau. Les drivers ignorent cette optimisation dans la majorité des cas et ne vois que "bête" adresse.
Donc ca voudrait dire que les drivers devraient se contrefoutre de ces histoires de X niveaux d'indirection. Ce qui veut dire que si on a une API de gestion de la MMU qui ne rend pas publique ces histoires de X niveaux d'uindirections, alors les drivers ne se porteront pas plus mal. Bref, cette remarque va dans le sens de ce qui suit...
> Linux tient compte du réel. Si le cpu a besoin x niveaux pour l'exploité, Linux n'a d'autre choix que de les implémenter. Si tu ne les utilises pas (entre autre pour distinguer mémoire virtuelle et physique) autant retourner sous DOS.
Le CPU, ou plutot la MMU (qui est certes dans le CPU sur x86), a besoin de ces x niveaux, en effet. Par contre, "tu" ne les utilises pas directement. Justement, une API de la gestion de la MMU est une interface coincee entre la MMU et "tu" : c'est une couche d'abstraction intermediaire pour que "tu" n'aies pas a s'e**erder avec des histoires de niveaux d'indirection (x86), de tables de hachage (ppc), etc.. et bien sûr c'est cette couche qui s'occupe de fournir le necessaire a la MMU (tables de traduction directes, de hachage, etc...).
[^] # Re: Il manque
Posté par fabb . Évalué à 0.
De quoi tu parles ?
> Le CPU, ou plutot la MMU (qui est certes dans le CPU sur x86), a besoin de ces x niveaux, en effet. Par contre, "tu" ne les utilises pas directement. Justement, une API de la gestion de la MMU est une interface coincee entre la MMU et "tu" : c'est une couche d'abstraction intermediaire pour que "tu" n'aies pas a s'e**erder avec des histoires de niveaux d'indirection (x86), de tables de hachage (ppc), etc..
Donc tout va pour le mieux dans le meilleur des mondes.
Pour ton histoire d'API je ne vois pas de quoi tu parles. L'API pour accéder à la mémoire est une adresse mémoire. Ce n'est pas un "truc" avec des indirections etc.
[^] # Re: Il manque
Posté par Brice Goglin . Évalué à 3.
> accéder à la mémoire est une adresse mémoire. Ce n'est pas un
> "truc" avec des indirections etc.
Il parle du fait qu'actuellement, si tu veux traduire une adresse virtuelle, en adresse physique, tu dois parcourir la table des pages à la main. Les indirections dont il parle, ce sont les etapes du parcours des differents niveaux de la table de page.
Actuellement, si t'as une adresse "addr" d'un espace d'adressage "mm", tu dois faire (en virant les routines les verifications) :
pgd = pgd_offset(mm, addr);
pud = pud_offset(pgd, addr);
pmd = pmd_offset(pud, addr);
pte = pte_offset_map(pmd, addr);
page = pte_page(*pte);
pte_unmap(pte);
Et enfin tu as le cadre physique "page" où est mappée ton adresse virtuelle.
Cette API ne correspond à rien sur certaines architectures qui utilisent autre chose d'une table de page.
Il serait donc mieux d'avoir une API du genre:
page = mmu_translate(mm, addr);
Et que mmu_translate fasse le code ci-dessus sur ia32 et fasse un truc adapté à l'architecture sur les autres.
C'est ce qui a été proposé recemment.
Voir "A proposal for a major memory management rework" dans
http://lwn.net/Articles/124966(...)
[^] # Re: Il manque
Posté par fabb . Évalué à 0.
> pgd = pgd_offset(mm, addr);
> ...
Qui doit faire/utiliser ça ?
Il n'y a que la partie du noyau qui gère la mémoire qui utilise ça (répertoire mm qui n'est pas lourd par rapport au reste).
C'est une API qui n'est pas exportée. C'est une API spécifique au hardware. Nul part (sauf répertoire mm) cette API est utilisée (sauf peut-être pour quelques cas d'optimisations).
Si tu fais un drivers, un fs, tout sauf ce qui n'est pas lié à la vm, tu ne touches jamais à ça.
Donc, tu ne parles pas d'API mais d'implémentation de la vm. C'est différent.
> Voir "A proposal for a major memory management rework" dans
http://lwn.net/Articles/124966(...)
Je n'y ai pas accès. Mais lis bien, c'est "A proposal for a major memory management rework". Ça ne conserne pas (mais je n'ai pas lu l'article) l'API qui est exporté.
[^] # Re: Il manque
Posté par Brice Goglin . Évalué à 4.
> Il n'y a que la partie du noyau qui gère la mémoire qui utilise ça
> (répertoire mm qui n'est pas lourd par rapport au reste).
Rien qu'en cherchant 3mn, j'ai le driver de ma webcam (spca50x) qui utilise ca, le DRM standard du noyau aussi, les drivers Myrinet, ...
Le noyau fournit aussi une API de plus haut niveau qui enrobe le parcours de page (par exemple pci_map_single). Et il ne faut pas oublier que le mapping linéaire permet de faire la translation rapidement avec virt_to_phys car on sait à l'avance ce que le parcours de la table de pages va donner.
Mais moralement, c'est la meme chose, les drivers veulent souvent traduire en adresses physiques.
Evidemment, ils utilisent la methode la plus simple.
Mais elle ne suffit pas toujours. Et dans ce cas, on utilise cette API.
> Donc, tu ne parles pas d'API mais d'implémentation de la vm. C'est
> différent.
Une API, c'est une "Application Programming Interface", ca veut dire interface logicielle de programmation. Ces fonctions sont exportées
dans les include/asm-/*.h de toutes les architectures.
Et un .h, c'est precisement un fichier où on ecrit les API.
> Je n'y ai pas accès. Mais lis bien, c'est "A proposal for a major
> memory management rework". Ça ne conserne pas (mais je n'ai
> pas lu l'article) l'API qui est exporté.
En effet, tu n'as pas lu l'article...
Par exemple :
"Christoph Lameter would like to get rid of the disconnect between in-kernel and hardware page tables; to that end, he has proposed a new abstraction layer which would handle access to the processor's memory management unit (MMU)."
puis
"The proposed replacement interface is somewhat vague at this stage, but some features have been sketched out:"
Une "nouvelle couche d'abstraction" puis une "interface de remplacement proposée", c'est une nouvelle API.
[^] # Re: Il manque
Posté par fabb . Évalué à -2.
$ find * -not -path "Documentation/*" -not -path "arch/*" -not -path "include/*" -not -path "mm/*" -print0 | xargs -0 egrep -n "(pgd_offset)|(pud_offset)|(pmd_offset)|(pte_offset_map)|(pte_page)|(pte_unmap)"
drivers/char/drm/drm_memory.h:127: pgd_t *pgd = pgd_offset_k((unsigned long) vaddr);
drivers/char/drm/drm_memory.h:128: pmd_t *pmd = pmd_offset(pgd, (unsigned long) vaddr);
drivers/char/drm/drmP.h:155:#ifndef pte_offset_map
drivers/char/drm/drmP.h:156:#define pte_offset_map pte_offset
drivers/char/drm/drmP.h:157:#define pte_unmap(pte)
drivers/char/drm/drmP.h:165: pgd_t *pgd = pgd_offset_k(addr);
drivers/char/drm/drmP.h:170: pmd = pmd_offset(pgd, addr);
drivers/char/drm/drmP.h:173: ptep = pte_offset_map(pmd, addr);
drivers/char/drm/drmP.h:176: page = pte_page(pte);
drivers/char/drm/drmP.h:177: pte_unmap(ptep);
fs/exec.c:313: pgd = pgd_offset(mm, address);
fs/exec.c:323: pte_unmap(pte);
fs/exec.c:331: pte_unmap(pte);
Voilà, c'est tout.
Impressionnant l'utilisation de l'API...
> Ces fonctions sont exportées dans les include/asm-/*.h de toutes les architectures.
Et les ficheirs dans include/asm sont spécifiques aux architectures !
Ils n'ont à être utilisé que si tu fais un truc SPÉCIFIQUE à l'architure et qu'en gros tu n'as pas le choix !
> Christoph Lameter would like to get rid of the disconnect between in-kernel and hardware page tables
Et alors ? Qui te dis que ça impacte l'API (or arch et include/asm car c'est SPÉCIFIQUE au hardware).
> Une "nouvelle couche d'abstraction" puis une "interface de remplacement proposée", c'est une nouvelle API.
Une API pour qui ?
Pour "mm/" seulement ?
[^] # Re: Il manque
Posté par Brice Goglin . Évalué à 2.
> Ils n'ont à être utilisé que si tu fais un truc SPÉCIFIQUE à l'architure
> et qu'en gros tu n'as pas le choix !
Un contre-exemple parmi des centaines :
Copier des données entre espace user et noyau est une chose très courante et que n'importe quel driver non-architecture-spécifique peut vouloir faire (relance ton find pour t'en rendre compte). Mais l'implémentation de copy_from_user est très architecture spécifique et exportée uniquement dans les asm/uaccess.h.
Les fichiers asm/*.h du noyau sont justement là pour masquer les choses dépendantes de l'architecture et fournir une interface uniforme.
Il est tout a fait normal pour n'importe qui d'inclure un fichier asm/*.h même pour programmer un truc pas du tout architecture spécifique.
> > Christoph Lameter would like to get rid of the disconnect
> > between in-kernel and hardware page tables
>
> Et alors ? Qui te dis que ça impacte l'API (or arch et include/asm
> car c'est SPÉCIFIQUE au hardware).
C'est facile de dire ca après avoir viré les parties intéressantes du texte que j'avais cité. Il dit explicitement qu'il veut créer une nouvelle couche d'abstraction des MMU et une interface de remplacement, c'est-à-dire une API :
"he has proposed a new abstraction layer which would handle access to the processor's memory management unit (MMU)."
"The proposed replacement interface is somewhat vague at this stage, but some features have been sketched out:"
(Je réinsère la citation pour voir si tu vas encore la virer).
Visiblement tu as très peu de connaissance du noyau et de sa programmation donc je vais te laisser continuer à troller tout seul
car je vous bien que je perds mon temps à essayer de t'expliquer les choses de la vie.
[^] # Re: Il manque
Posté par fabb . Évalué à -3.
> > Ils n'ont à être utilisé que si tu fais un truc SPÉCIFIQUE à l'architure
> > et qu'en gros tu n'as pas le choix !
J'ai écrit une connerie car t'as écrit une connerie :
- Ces fonctions sont exportées dans les include/asm-/*.h de toutes les architectures.
Je voulais dire "include/asm-*".
Pour priciser :
include/asm : API indépendante de l'architecture
include/asm-* : API dépendante de l'architecture
Que asm soit un lien sur asm-* ne change rien.
Lorsque tu fais "include <asm/*.h>" tu signifies : j'ai besoin de l'API générique (portable (indépendante du hardware)).
Lorsque tu fait "include <asm-*/*.h>" tu signifies : j'ai besoin de l'API spécifique à un hardware. Donc normalement "include/asm-*" n'est pas utilisé hors "arch/*".
> Visiblement tu as très peu de connaissance du noyau et de sa programmation
Connard.
[^] # Re: Il manque
Posté par Brice Goglin . Évalué à 3.
> - Ces fonctions sont exportées dans les include/asm-/*.h de
> toutes les architectures.
N'essaie pas de te cacher derrière des caractères manquant ou en trop. Ma phrase reste parfaitement vraie que ce soit asm ou asm-*.
grep est là pour le prouver.
Les gens qui incluent pgtable.h pour utiliser pgd_offset and co, ils incluent bien asm/pgtable.h et pas asm-*/pgtable.h.
C'est le cas dans drm et dans fs que tu avais cités avec ton find, et également dans le driver de ma webcam et le driver Myrinet.
> Lorsque tu fais "include <asm/*.h>" tu signifies : j'ai besoin de l'API
> générique (portable (indépendante du hardware)).
> Lorsque tu fait "include <asm-*/*.h>" tu signifies : j'ai besoin de l'API
> spécifique à un hardware. Donc normalement "include/asm-*" n'est
> pas utilisé hors "arch/*".
Exactement, c'est ce qui permet de conclure que l'API pgd_offset and co. est bien independante de l'architecture.
CQFD.
[^] # Re: Il manque
Posté par fabb . Évalué à 1.
Et comme indiqué plus haut, ce n'est pas ou peu utilisé. C'est utilisé que s'il n'y a pas le choix. L'architecture ou certain driver l'impose mais pas Linux. Linux doit faire avec ce que lui fournit le hardware.
[^] # Re: Il manque
Posté par David Decotigny (site web personnel) . Évalué à 2.
Bref, une API noyau n'est pas forcement utilisee par les drivers directement. C'est pas pour ca qu'on doit dire "boarf, c'est de la cuisine interne au noyau, c'est forcement bas niveau, donc ca depend du matos et le noyau se debrouille.". Non. Par exemple, pour la MMU, c'est pas parce que c'est utilise essentiellement par VMM (le sous-systeme de gestion de la mem virtuelle) que ca ne doit pas etre une API a part entiere, claire et precise. Parce qu'une contrainte des noyaux du genre Linux, c'est qu'il doit etre "portable", ie adaptable a plusieurs archi en touchant le moins de code possible. Dans Linux comme dans les Unix, la VMM, interne au noyau, doit avoir le meme comportement dans toutes les archi, et donc, si possible *partager* le meme code pour toutes les archi. Quelle autre solution pour ca que de dire que VMM repose sur une API de gestion de la MMU uniforme sur toutes les archis ?
Bon, j'espere que jusqu'ici c'est clair. Maintenant qu'on a dit qu'une API de gestion de la MMU etait necessaire (bien que peu de drivers l'utilisent directement), la question se pose de la definir. Dans Linux, l'histoire a choisi une API a base de tables simples avec 2 ou 3 indirections (resp 3 ou 4 niveaux de tables). Eh bien je ne suis pas convaincu que ce soit le meilleur choix. D'une part parce que cette API est un gouffre en termes de perf quand l'archi ne repose pas sur un systeme a indirection simple parce que emuler en soft ce systeme peut etre tres complexe quand on ne dispose pas en hard des elements en question (ex : ppc repose sur une serie de tables de hachage, pas facile d'emuler des tables a indirection a partir de ca). D'autre part parce que le code de gestion de la VMM n'a pas un besoin fondamental de gerer des tables a 2 ou 3 indirections : il est essentiellement question d'etablir des traductions adresse virtuelle -> physique, pas de dire que l'entree 12 de la table de niveau 4 pointe sur la table a l'adresse physique 0x1234000, etc... Si la VMM pouvait se passer de ce genre de detail, ca serait quand meme plus elegant.
Pour Brice : vivement Jeudi que je lise cet article lwn ! Si ca continue je m'abonne.
[^] # Re: Il manque
Posté par fabb . Évalué à 1.
Je suis parfaitement d'accord. Mais lorsqu'on parle API il faut être précis. Si on me parle d'API de la vmm sans plus de précision, je pense à l'API utilisable par un module externe et pas au sein du système de gestion de la vmm.
Si je dis que l'API de libxml2 est bien faite, tout le monde comprend que je parle de l'API "externe" et pas de la tembouille interne.
> Dans Linux comme dans les Unix, la VMM, interne au noyau, doit avoir le meme comportement dans toutes les archi, et donc, si possible *partager* le meme code pour toutes les archi.
Pas totalement d'accord. Dans l'idéal, ça doit être le même code. Ce qui compte avant tout c'est que l'interface, l'API "externe", soit la même pour tout le monde.
De tout manière, il est *impossible* d'avoir le même code pour toute les architectures, ou plus précisément il y a toujours un moment ou tu dois prendre en compte les spécificité de l'architecture pour des raisons de performance. C'est bien le role du noyau (ou de tout module réutilisable) de prendre en compte les spécificités et de les masquer. Mais au final il faudra *toujours* du code spécifique.
> Quelle autre solution pour ca que de dire que VMM repose sur une API de gestion de la MMU uniforme sur toutes les archis ?
Tu peux toujours repousser l'encapsulation. Savoir où et jusqu'où il faut le faire n'est en rien évident (surtout pour un noyau ou le critère performance est très important).
Tu peux faire un noyau en java, mais c'est lent et le code spécifique que tu as retiré en utilisant java, tu le retrouves dans java. Le gain est nul.
> D'autre part parce que le code de gestion de la VMM n'a pas un besoin fondamental de gerer des tables a 2 ou 3 indirections : il est essentiellement question d'etablir des traductions adresse virtuelle -> physique, pas de dire que l'entree 12 de la table de niveau 4 pointe sur la table a l'adresse physique 0x1234000, etc... Si la VMM pouvait se passer de ce genre de detail, ca serait quand meme plus elegant.
L'interface (externe) se passe de ce genre de détail (sauf pour quelques cas rarement utilisé). Donc la voie est libre pour implémenter différement la VMM où même faire une VMM totalement spécifique à ppc sans retoucher (ou peu) l'API externe.
Au final et pour être bien d'accord. Je ne vais pas dire les avantages ou inconvénient des techniques de telle ou telle vmm. Je n'ai pas les compétences. Ce qui m'"énerve" c'est de voir les gens parler d'_API_ en des définissants comme spécifiques à une architecture.
Ce que tu reproches à la vmm ici (et si j'ai bien compris) a du sens. Tu ne reproches pas l'API (externe) mais que la vmm "colle" que système qu'on retrouve sur les systèmes types x86 et que ce n'est pas forcement la bonne aproche pour toutes les architectures. Tu ne demandes pas que l'API (externe) soit encore plus neutre par rapport au architecture mais que son fonctionnement interne soit plus neutre et pas "optimisé" pour un type d'architecture.
Je n'ai pas de problème avec ça.
[^] # Re: Il manque
Posté par Brice Goglin . Évalué à 2.
Tu peux aussi aller lire directement l'annonce sur la LKML :
http://marc.theaimsgroup.com/?l=linux-ia64&m=110922543030922&w=2
# Ahh
Posté par Guillaume D. . Évalué à 4.
et xen c'est pour quand ?
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/(...)
J'ai lu quelque part que c'etait pour le 2.6.12, quelqu'un confirme ?
ici :
http://www.crn.com/sections/breakingnews/breakingnews.jhtml?article(...)
Merci
# InfiniBand...
Posté par Guillaume POIRIER . Évalué à 10.
Il me semble que cette définition est inexacte (cf http://www.oreillynet.com/pub/a/network/2002/02/04/windows.html(...) )
L'infiniband, c'est plutôt une technologie d'interconnection caractérisée par une faible latence et un gros débit, et est plutôt présenté comme un remplaçant d'ethernet ou mirinet pour les calculs sur grid.
Bon, si on regarde sur le wikipedia: http://en.wikipedia.org/wiki/InfiniBand(...) il semble bien qu'Infiniband se veut comme un remplaçant d'autant ethernet que le bus PCI...
Tout ça pour dire que jusqu'à présent, on pouvait difficilement avoir des gros débits de noeuds à noeuds en réseau local avec des technologies courantes, mais que heureusement est arrivé Infiniband!
[^] # Re: InfiniBand...
Posté par Maxime Ritter (site web personnel) . Évalué à 6.
Par contre, rien à voir avec les calculs sur grid. Dans les grids, la vitesse de communication entre les noeuds est extremment aléatoire, ils ne sont pas concus pour faire tourner des programmes ayant de gros besoin de communication entre eux. Pas de MPI sur les grids en général, alors qu'au contraire avec Infiniband, on n'utilisera à 90% des programmes basés sur MPI (ou son ancêtre PVM).
[^] # Re: InfiniBand...
Posté par Brice Goglin . Évalué à 4.
> d'être un standard, donc on n'est plus cantonné à un seul
> fournisseur.
C'est la théorie ça.
En pratique, il n'y a que Mellanox qui produit réellement du matériel.
Il y a pas mal "d'assembleurs" InfiniBand en quelque sorte. Mais au final c'est pas si différent de Quadrics et Myrinet qui sont les seuls a produire leur matériel respectif.
Au niveau performance, la bande passante annoncée (12x voire 30x, c'est à dire 3Go/s voire 7,5Go) est enorme mais completement inobservable en pratique puisque les bus d'entrées-sorties des machines actuelles ne supportent guere plus que ce que InfiniBand 4x promet.
Donc au final, en bande passante c'est pareil que Quadrics (qui reste la référence du marché).
En latence, c'est beaucoup moins bons que Quadrics et Myrinet (moins de 2 et 3us respectivement) alors qu'Infiniband passe difficilement sous les 5-6us.
SCI a quasiment disparu du marché depuis quelques années déjà.
# InfiniBand, c'est un réseau pour grappes
Posté par Brice Goglin . Évalué à 10.
performances utilisées dans les grappes de calcul.
En gros, c'est 5-10 microsecondes et 1Go/s.
Mais pour cela, il faut utiliser un protocole et des applications très speciales.
Le vrai support de ce protocole natif haute performance ne sera probablement jamais inclu car il est trop intrusif et concerne tres peu de gens.
Là, ils ont simplement inclu dans le noyau le support du protocole IP pour ces cartes.
# Imodules proprio NVIDIA
Posté par Rin Jin (site web personnel) . Évalué à 2.
http://unixforge.org/~matthias-christian-ott/index.php?entry=entry0(...)
[^] # Re: Imodules proprio NVIDIA
Posté par dromadaire35 . Évalué à 6.
http://www.nvnews.net/vbulletin/showthread.php?t=46676(...)
[^] # Re: modules proprio NVIDIA
Posté par Amand Tihon (site web personnel) . Évalué à 7.
[^] # Re: modules proprio NVIDIA
Posté par mansuetus (site web personnel) . Évalué à 3.
j'ai installé le 2.6.11 en croisant les doigts, make && make install && make modules_install
ça boot !
j'installe le driver NVIDIA, startx, et poof, ça marche !
là, je lance ma carte TV, ça freeze (comme d'hab) et je reboot (reset button), et là, plein de UNEXPECTED SYMBOL au moment du chargement NVidia.
solution : ré-installer le driver à chaque reboot, en attendant le patch :/
(rude, but woks)
Mes2cents
[^] # Re: modules proprio NVIDIA
Posté par Alexandre Dombrat . Évalué à 2.
[^] # Re: modules proprio NVIDIA
Posté par lapougnou . Évalué à 6.
Le fait de dire cents au lieu de centimes doit être pour faire plus djeuns...
[^] # Re: modules proprio NVIDIA
Posté par Alexandre Dombrat . Évalué à 2.
[^] # Re: modules proprio NVIDIA
Posté par nigaiden . Évalué à 2.
Sur les pièces françaises, il est bien marqué "cent" et non pas "centime". Ce qui me choque le plus, c'est que sur ces mêmes pièces, le nom n'est pas accordé ; ainsi on a "10 euro cent" alors que j'aurais plutôt mis "10 euro cents".
# 2.6.12
Posté par tgl . Évalué à 8.
- FUSE (système de fichiers en user space, à la LUFS et compagnie)
- cpusets: un système de partitionnement des resources CPU des machines SMP (en gros si je comprends bien, à la fois de la virtualisation et de l'allocation explicite des ressources CPU à certaines tâches)
Et puis plein d'autres choses, dont rien de garanti bien sûr.
http://kerneltrap.org/node/4789(...)
[^] # Re: 2.6.12
Posté par udok . Évalué à 2.
[^] # Re: 2.6.12
Posté par gnumdk (site web personnel) . Évalué à 4.
[^] # Re: 2.6.12
Posté par fabb . Évalué à 2.
la partie vfs tourne en kernel space, le reste en user space.
> le hurd propose quelque chose de mieux ;)
c-à-d ?
la partie vfs est en user space ?
[^] # Re: 2.6.12
Posté par fabb . Évalué à 1.
# Macs
Posté par Colin Leroy (site web personnel) . Évalué à 6.
[^] # Re: Macs
Posté par Michel Pastor . Évalué à 1.
Félicitation a BenH qui fait vraiment du très bon boulot.
Il ne manque plus que le support du chipset Airport Broadcom pour finaliser le support des portables Apple car il faut dire que c'est quand même un gros handicap pour linux sur Mac (surement pas pour tout le monde mais pour moi ça en est un gros).
# 2.6.11 sur laptop ASUS W1N
Posté par brunus (site web personnel) . Évalué à 6.
Le son fonctionnait mais les HP n'étaient pas activés.
Sur les noyaux précédents il fallait compiler avec les options de debug pour ALSA et forcer à la main les valeurs suivantes pour les registres :
echo -n "26 000F" > /proc/asound/card0/codec97#0/ac97#0-0+regs
echo -n "36 0000" > /proc/asound/card0/codec97#0/ac97#0-0+regs
echo -n "64 7110" > /proc/asound/card0/codec97#0/ac97#0-0+regs
[^] # Re: 2.6.11 sur laptop ASUS W1N
Posté par Julien MOROT (site web personnel) . Évalué à 3.
# Version de développement
Posté par ouah (site web personnel) . Évalué à 5.
http://lkml.org/lkml/2005/3/2/247(...)
[^] # Re: Version de développement
Posté par FueL . Évalué à -1.
[^] # Re: Version de développement
Posté par FReEDoM (site web personnel) . Évalué à 4.
he he :)
[^] # oops pardon
Posté par FReEDoM (site web personnel) . Évalué à 2.
[^] # Re: oops pardon
Posté par herodiade . Évalué à 4.
From: Linus Torvalds <torvalds () osdl ! org>
"[...]I think we should drop the
original even/odd suggestion for now, and see if this would make more
sense.."
http://marc.theaimsgroup.com/?l=linux-kernel&m=110987495523158&(...)
[^] # Re: oops pardon
Posté par Brice Goglin . Évalué à 1.
Mais beaucoup de developpeurs pensent que les gens vont arreter de tester les 2.6.impair. Retour au probleme initial donc.
De plus, cela aurait imposé des delais d'attente plus grand pour tous les gens qui veulent soumettre des patchs.
Donc, Linus and co. ont finalement décidé de garder le modèle actuel en ajoutant une vraie branche 2.6.x.y comme cela avait été fait avec 2.6.8.1 pour fixer un enorme bug NFS.
Greg KH va (pour commencer) maintenir 2.6.11.x (et a deja sorti 2.6.11.1 ce soir).
La branche 2.6.x.y sera susceptible de recevoir tous les petits patchs fixant des choses vraiment importantes.
Des que 2.6.(x+1) sortira, la branche 2.6.x.y sera stoppée.
# No medium found
Posté par VoixOff . Évalué à 3.
Les rescan-scsi.sh, echos 1 > /sys/.../rescan, le paramétrage de udev pour pré-allouer les pilotes, n'ont aucun effet. J'ai testé tout ce que Google me trouvait.
Tout est là, dans /dev, la log indique que tout est reconnu...
Ça marchait à une époque (sur un 2.4 c'est sûr, mais y'a pas udev - qui m'a incité à passer au 2.6), mais ça ne marche plus. Je nourrissais quelque espoir pour ce nouvo noyo, en vain.
Devrai-je faire une recherche dichotomique pour retrouver un kernel qui marche (pas glop), ou bien quelqu'un aurait-il une solution miraculaire ?
AU SECOURS :-)
[^] # Re: No medium found
Posté par ebdomino . Évalué à 2.
http://ebdomino.free.fr/lecteur_multi_cartes.html(...)
??
tiens moi au courant
[^] # Re: No medium found
Posté par VoixOff . Évalué à 2.
J'ai viré mes "renommages" udev, on ne sait jamais.
J'avais bien "Probe all LUNs..." activé (et j'avais lu que ça dispensait du paramètre "max_scsi_luns", mais j'ai testé quand même).
Ce qui est frustrant, c'est qu'il reconnait tous les lecteurs (SMC, CFC, MMC, MSC), il dit qu'il les attache à sd[a..d], et effectivement, je les retrouve dans /dev.
(D'ailleurs j'ai le même résultat que je branche d'abord le lecteur puis que j'y glisse la SD ou que je branche le lecteur avec la SD déjà connectée.)
Mais le mount est toujours aussi agaçant...
Le seul truc qui semble rester, c'est les pilotes USB compilés dans le noyo plutôt qu'en modules. Au fait, je n'ai activé le support d'aucun lecteur en particulier (sous "USB Mass Storage support") puisqu'il *semble* être reconnu.
Bord... c'est le premier truc qui me résiste autant sous Linux, grrr
[^] # Re: No medium found
Posté par ebdomino . Évalué à 1.
http://people.via.ecp.fr/~alexis/formation-linux/config/config-2.6.(...)
j'utilises cette conf comme base.
a+
# Oui, mais ...
Posté par tchibitchi . Évalué à 2.
Alors le 2.6.11 ! :)
/!\ débranchez vos trollomètres, je confirme que c'en était un ! :)
Dommage que debian ne mette pas à dispo les sources des différents noyaux patchés, histoire qu'on puisse nous même se les compiler sans problème.
[^] # Re: Oui, mais ...
Posté par Brice Goglin . Évalué à 3.
Le 2.6.10 est dans sid. Le 2.6.9 y a surement été avant.
> Dommage que debian ne mette pas à dispo les sources des
> différents noyaux patchés, histoire qu'on puisse nous même se les
> compiler sans problème.
Il est vraiment si difficile d'aller telecharger les sources toi-meme sur kernel.org ?
Sinon le petit utilitaire ketchup permet de recuperer automatiquement le dernier noyau -rc, -mm, .... Très utile.
[^] # Re: Oui, mais ...
Posté par tchibitchi . Évalué à 1.
Non, car je suis déjà sous un 2.6.11.
Cependant, j'ai beau faire un coup de
root@brouettej ~ #>apt-cache search 2.6.1| grep -i kernel
kernel-patch-2.6-bluez - Linux Bluetooth protocol stack kernel patches
kernel-patch-lkcd - linux Kernel Crash Dump - kernel patch
Pas de kernel-source, ni de header, ni de binaire, etc...
Perso, je préfère compiler les sources du noyaux patchées par Debian.
Bon, cela dit, make bzImage, make modules, make modules_install, mkinitrd -o /boot/initrd-2.6.11N 2.6.11N, ça n'est effectivement pas très difficile ! :)
[^] # Re: Oui, mais ...
Posté par Sylvain Sauvage . Évalué à 2.
(Ça fonctionne aussi très bien avec des noyaux de kernel.org !)
[^] # Re: Oui, mais ...
Posté par Brice Goglin . Évalué à 2.
> Perso, je préfère compiler les sources du noyaux patchées par
> Debian.
Le noyau 2.6.10 précompilé est dans sid, pas dans sarge (dont le noyau standard est 2.6.8). C'est pareil pour les sources.
kernel-source-2.6.10 est dispo dans sid.
kernel-headers n'a plus vraiment d'utilité depuis 2.6 car (contrairement à 2.4), il faut beaucoup plus que quelques fichiers.h pour pouvoir compiler un module externe.
Ceci dit, je suis d'accord, Debian n'est vraiment pratique pour recuperer facilement les sources de leurs noyaux precompilés
(ou le patch associé). C'est vraiment fatiguant quand on veut compiler un module externe.
Par contre, comme Debian applique très peu de patchs (contrairement à Redhat ou Mandrake), partir d'un noyau Vanilla est finalement pas très différent. Si vraiment on veut un noyau proche de Debian, on peut appliquer eventuellement le patch -as qui est justement géré par le mainteneur Debian et sert de base au noyaux précompilés.
> Bon, cela dit, make bzImage, make modules, make modules_install,
> mkinitrd -o /boot/initrd-2.6.11N 2.6.11N, ça n'est effectivement pas
> très difficile ! :)
Surtout que depuis 2.6, il suffit de faire "make" au lieu de "make bzImage" et "make modules" comme précedemment...
[^] # Re: Oui, mais ...
Posté par tchibitchi . Évalué à 1.
Sans vouloir dire que j'ai une machine de production chez moi, je ne me limite qu'aux paquets de la testing. C'est que, si je peux supporter que certaines fonctionnalités soient déficientes par ma faute, il n'en est pas forcément de même pour les autres utilisateurs ;)
kernel-headers n'a plus vraiment d'utilité depuis 2.6 car (contrairement à 2.4), il faut beaucoup plus que quelques fichiers.h pour pouvoir compiler un module externe.
Damned ! Je n'avais pas l'info. Donc, je m'embête pour rien quand j'installe les kernel-headers du 2.6.8 ? Dépaqueter les sources, ça suffit ?
Une feature qui m'avait bloquée pour compiler moi-même mes noyaux, dernièrement, c'est qu'à l'install du noyau compilé via make-kpkg, mkinitrd rate parce-qu'il cherche les modules dans /lib/modules/<nom_correct>N
Je ne sais pas d'où sort ce "N", mais le noyau ne s'installe pas correctement. Alors, bien sûr, on peut contourner, mais j'ai par habitude de ne pas faire de choses hasardeuses lorsqu'il s'agit du noyau.
Voilà pourquoi je regrettais que les 2.6.10 et Cie n'étaient pas présents dans testing, ...
Merci pour les réponses en tout cas.
[^] # Re: Oui, mais ...
Posté par fabb . Évalué à 1.
Faut te renseigner, depuis Fedora Red Hat applique peu de patch. Leur objectif est de bosser le plus possible en upstream. Il n'y a que RHEL qui est beaucoup patché.
Faut bien comprendre que les distributeurs ne font pas ça de gaité de coeur. C'est une nécessité.
[^] # Re: Oui, mais ...
Posté par Brice Goglin . Évalué à 1.
C'est pour ca que j'avais dit Red Hat et pas Fedora...
[^] # Re: Oui, mais ...
Posté par fabb . Évalué à 1.
# Pas de ports ps2 en 2.6.11
Posté par ebdomino . Évalué à 3.
depuis le 2.6.5 compilé avec les sources kernel.org aucun soucis (2.6.7, 2.6.9, 2.6.10 actuellement)
mais lors de la compil du 2.6.11 avec la configuration du 2.6.10, au reboot tout se passe bien aucune erreur sauf que mes ports ps2 ne marchent plus.
pas de clavier et pas souris. n'ayant rien toucher à la configuration, et en ayant vérifié à plusieurs yeux que tous les modules nécessaires au ps2 avaient été compilés, je n'ai pas résolu l'affaire !
suis je le seul?
0000:00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4)
pour la carte.
et la souris logitech usb/ps2 IR 3 boutons clavier ps2 de base .
testé avec et sans les driver nvidia
testé module dans et hors noyau
aucune erreur, X se charge mais pas de souris
a+
[^] # Re: Pas de ports ps2 en 2.6.11
Posté par herodiade . Évalué à 4.
Si oui, peut-être devrait tu essayer le 2.6.11.1 (http://www.kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/)(...)
[^] # Re: Pas de ports ps2 en 2.6.11
Posté par ebdomino . Évalué à 1.
a+
[^] # Re: Pas de ports ps2 en 2.6.11
Posté par ebdomino . Évalué à 1.
merci beaucoup herodiade je viens de compiler le 2.6.11.1 et ma souris fonctionne.
a+
# drm et dc10 \o/
Posté par cortex62 . Évalué à 1.
le module drm des ati r2** est amélioré ( vérifié ET tourne mieux).
et le module zoran mjpeg est amélioré (peut être que je pourrais capturer en couleur maintenant)
\o/
[^] # Re: drm et dc10 \o/
Posté par Denis Montjoie (site web personnel) . Évalué à 1.
perssonne ne ma repondu la http://linuxfr.org/forums/10/7271.html
j'hesitais a poster ici mais vu que plein de gens ont posté pour les drivers nvidia.
pour ceux qui ont le flemme de cliquer sur le lien:
Bonjour
Je dispose d'une carte DC10+ (Chipset Zoran) et depuis le 2.6.1 jusqu'au 2.6.10 elle marchait sans problème (option en brut dans le kernel).
Mais avec le 2.6.11 elle stop carémment le boot du kernel en me mettant:
"cannot load module saa7110" et "cannot load module adv7175".
Même pas de kernel panic, un gros freeze. (j'avais deja ces erreurs la avant mais ca marchait tres bien)
J'ai donc essayer de tous mettre en module mais la je constate qu'il n'existe pas de module saa7110 et adv7175 a cocher...
J'ai donc tous coché dans "video for linux".
Et effectivement il me compile des modules saa7110 et adv7175.
Malheuresement ca marche toujours pas.. crash avec les modules.
Donc trois questions:
-Quelqu'un a t'il le même problème et/ou une solution?
-Comment se fait-il qu'il y ai des modules "caché" qui n'apparraisent pas dans les choix? (je subodore qu'il sont produits par le module dc10+ mais bon...
-J'aimerais avoir un kernel sans module (c'est mon choix) d'où le fait que tous est en "brut" MAIS comment se fait il qu'il me réclame des modules alors que j'en ai pas activé le support? (bug?,normal?)
Merci d'avance
[^] # Re: drm et dc10 \o/
Posté par cortex62 . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.