mardi 30 juin

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Logiciel

Liens connexes

Les nouveautés du noyau 2.6.26 (2532 hits)
Le bilan des ajouts partie 1 (496 hits)
Le bilan des ajouts partie 2 (355 hits)
Le bilan des ajouts partie 3 (337 hits)
les changements d'API du 2.6.26 (494 hits)
Les prévisions pour l'avenir de Linux (1050 hits)

Dépêche modérée par

jerome_misc

Dépêche éditée par

Logiciel : Sortie du noyau Linux 2.6.26

Posté par patrick_g (page perso, ). Modéré le 14 juillet 2008.

La sortie de la vingt-septième version stable de la branche 2.6 du noyau Linux vient d'être annoncée par Linus. Vous pouvez donc dès maintenant télécharger le code source du nouveau noyau sur les serveurs du site kernel.org.

NdM : le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche.

Les nouveautés du noyau 2.6.26 (2532 hits)
Le bilan des ajouts partie 1 (496 hits)
Le bilan des ajouts partie 2 (355 hits)
Le bilan des ajouts partie 3 (337 hits)
les changements d'API du 2.6.26 (494 hits)
Les prévisions pour l'avenir de Linux (1050 hits)

> Lire la suite (58 commentaires, moyenne: 3,6). [dépêche : 27383 caractères]

La phase de test...

Selon Linus cette version 2.6.26 n'est techniquement pas très risquée et le 3 mai, dans son courriel d'annonce de la RC-1, il écrit : "La période de merge a été mouvementée car il y a eu beaucoup de discussions et de disputes mais, dans le même temps, je pense que sur un angle technique nous avons intégré des choses moins effrayantes que cela n'était le cas auparavant. Beaucoup de changements mais rien de vraiment fragile.
Une autre fonctionnalité qui est notable, non par sa taille mais parce que les gens avaient essayé de me le faire intégrer depuis longtemps, est le support de kgdb. Cela s'est révélé être du code vraiment petit et propre, une fois que les gens ont commencé à orienter leurs efforts pour que cela soit le cas. Kgdb est le nom d'un débogueur du noyau Linux au niveau code source.
La RC-2 du 12 mai a confirmé ce sentiment d'une version du noyau sans problèmes notables de stabilité : "Si vous lisez le résumé des corrections et en retirez le sentiment qu'il s'agit d'une liste de petits trucs barbants vous aurez raison. Il n'y a pas grand chose d'excitant là-dedans.
Le 18 mai, pour la sortie de la version candidate RC-3, Linus a évoqué un anniversaire assez inattendu : "Une chose intéressante (du moins pour moi) est que nous utilisons git depuis presque la même durée que nous avons utilisé BitKeeper - un peu plus de trois ans. Nous avons commencé à utiliser BK en février 2002, avec un point final pour la version 2.6.12-rc2 au début avril 2005. Le premier commit avec git a pris place deux semaines plus tard.
Donc, du fait de cet évènement, j'ai regardé quelques statistiques de l'époque BK et de l'époque git. La différence la plus frappante (...) est que nous développons plus vite et avec plus de gens. Pendant les années 2002->2005 il y a eu 63428 commits attribués à environ 1560 auteurs différents. Pendant les trois dernières années il y a eu 96885 commits attribués à environ 4068 auteurs différents.
Cette petite recherche statistique effectuée par Linus prouve que la communauté des développeurs du noyau est plus active que jamais. Avec +52,7% pour les commits et +160,7% pour les auteurs on a la preuve que le processus de développement actuel résiste à la charge et que le travail sur le noyau Linux augmente d'année en année.
Les versions candidates suivantes sont apparues au rythme normal et habituel d'une par semaine environ. La RC-4 le 26 mai (avec un Linus poussant un petit grognement contre les "pervers" qui utilisent un noyau 32 bits alors qu'ils ont un processeur 64 bits et plus de 4 Go de mémoire), la RC-5 le 4 juin et la RC-6 le 12 juin.
La version candidate RC-7 du 20 juin a vu l'inclusion (très tardive dans le cycle) des pilotes 3D pour les cartes Radeon R500 et la mise à jour des pilotes pour les cartes Intel de type GMA-4. Cette inclusion de dernière minute n'a pourtant pas soulevé de protestations particulières : "Je ne suis pas vraiment heureux de la date d'inclusion de ces nouvelles cartes mais en même temps je déteste retarder l'inclusion de nouveaux pilotes. Évidemment l'espoir est que cela ne causera aucune régression car le code qui a été ajouté est presque entièrement pour des trucs qui n'étaient de toute façon pas supportés auparavant.
Dès le 24 juin est apparue la RC-8 : "Je sais, cela ne fait pas une semaine depuis la RC-7 et la liste des changements est très réduite, mais comme je ne vais pas être joignable durant les prochains jours je sors juste cette RC-8 en espérant que ce sera la dernière. Ou pas. Cela dépendra du fait de savoir si vous êtes efficaces quand je ne vous surveille pas.
Le 5 juillet Linus a annoncé la sortie de la RC-9 :"OK, la dernière RC n'était pas la dernière après tout puisqu'en voilà une nouvelle. Il y a eu suffisamment de changements pour que nous ayons besoin d'une version de plus. Mais cela devrait fermer de nombreuses entrées dans la liste des régressions donc ce n'est pas plus mal.
Il y a aussi quelques patchs de nettoyage tardifs qui me viennent d'Al. Pas cool, Al. Mais quand Al m'envoie des patchs je les applique. Cela m'inquiète de penser à ce qui pourrait arriver si je ne le faisais pas.

Les nouveautés...

Le support de PAT (Page Attribute Table) a été ajouté dans le noyau pour l'architecture x86. Cette technologie a eu une longue et difficile gestation (depuis 2006 !) mais son arrivée va permettre au système d'exploitation libre de gérer plus finement les caches mémoire. Auparavant c'était seulement la technique MTRR (Memory Type Range Registers) qui était utilisée. Elle permettait de changer le comportement des caches mémoire mais seulement pour un nombre limité d'adresses physiques. PAT est bien plus souple d'utilisation et permet de définir des attributs sur chacune des pages mémoire ce qui va constituer un complément utile de MTRR. La documentation permet de comprendre plus précisément comment fonctionne cette notion d'attributs au niveau des pages mémoires.
Le noyau 2.6.26 corrige une faiblesse sur la fonction mount --bind. Cette fonction permet très facilement de monter une arborescence sur un second point de montage. Si par exemple j'ai un disque dur qui se trouve dans "/mnt/sda1" et que je veux le mettre aussi dans "/mon_conteneur/plop", je dois créer le dossier de destination et lancer la commande "mount --bind /mnt/sda1 /mon_conteneur/plop". On peut par exemple utiliser le mount --bind pour exporter une arborescence dans un conteneur.
L'ennui c'est que ce second point de montage aura exactement les mêmes options de mount que le premier. Si je veux monter mon mount --bind en lecture seule alors que le premier montage a été fait en lecture/écriture cela n'est pas possible (ce qui est gênant car il est souvent nécessaire de pouvoir exporter en lecture seule dans un conteneur virtuel). Le noyau 2.6.26 offre donc maintenant la possibilité d'avoir des options de montage différentes sur son mount --bind. Pour des raisons techniques il faut monter une première fois le mount --bind en lecture/écriture puis le remonter ensuite en lecture seule. Les développeurs du noyau ont donc du prévoir le cas tordu ou un processus ouvre un fichier en écriture juste entre les deux opérations de mount. L'article de LWN explique bien tous les petits détails sordides dont il a fallu tenir compte pour permettre de gérer ce problème potentiel.
En définitive la possibilité de faire des mount --bind en lecture seule va permettre de monter de façon plus souple et plus riche les systèmes de fichiers et cela sera certainement fort utile en cas d'utilisation intensive des conteneurs virtuels.
Le patch implémentant la notion de bit de sécurité par processus a été ajouté au noyau 2.6.26. Ainsi, au lieu d'avoir des applications qui fonctionneront avec les droits de root (applications "setuid"), il devient possible de ne plus élever les privilèges de ces applications de façon exorbitante. Actuellement cette fonction est désactivée par défaut et il faut compiler son noyau avec CONFIG_SECURITY_FILE_CAPABILITIES pour l'activer.
Étant donnée l'inclusion dans le noyau précédent du module de sécurité SMACK il faut maintenant gérer la cohabitation avec SELinux qui est l'autre module existant dans la branche principale. Un nouveau paramètre de boot fait donc son apparition pour savoir quel module doit être chargé par LSM (Linux Security Modules): En utilisant le paramètre "security=" il devient possible de choisir quel module sera chargé dans le noyau (SELinux ou SMACK) et si ce paramètre n'est pas renseigné c'est le premier module à faire la demande qui sera chargé par LSM.
Toujours dans les paramètres de boot il est maintenant possible de tester la mémoire lors du démarrage de la machine. Avec ce nouveau noyau 2.6.26 il suffit de passer "memtest=4" au boot pour que cette fonction s'active (si le noyau a été compilé avec l'option MEMTEST_BOOTPARAM). Bien entendu cette nouveauté ne vise pas à remplacer le très complet memtest mais il permet d'avoir un outil basique intégré dans le noyau (qui donc potentiellement pourra par la suite fonctionner sur de multiples architectures alors que memtest est limité aux x86).
Le débogueur kgdb a été finalement intégré au noyau pour l'architecture x86, après des années de pression de la part de nombreux développeurs et une âpre résistance de la part de Linus Torvalds qui a souvent exprimé son dédain pour cette solution. Pour passer le barrage de Linus il a été nécessaire de modifier kgdb afin de s'assurer de la parfaite propreté du code et de l'absence d'impact sur le reste du noyau. Une fois que Linus a été convaincu que le patch était aussi peu intrusif que possible il a donné son feu vert pour l'inclusion.
le débogueur KGDB s'utilise avec deux machines (seulement architecture x86 ou SPARC pour l'instant) : l'une est la machine de test qui exécute le noyau qu'il faut déboguer et l'autre exécute une instance de gdb et est reliée à la première par liaison rs232 ou ethernet.
Une documentation au format DocBook a été ajoutée et permet de débuter dans le monde merveilleux du déboguage noyau.
L'implémentation des sémaphores a été radicalement simplifiée dans le noyau 2.6.26. En effet depuis le noyau 2.6.16 un large mouvement de conversion de code a été entrepris afin de changer les sémaphores pour les remplacer par des mutex. Les sémaphores permettent de contrôler l'accès a des ressources quand plusieurs processus se font concurrence. Pour cela les sémaphores embarquent un compteur mais pourtant dans la pratique la limite est presque toujours fixée à 1 (un seul processus doit avoir accès à la ressource à un moment donné). Pourquoi alors s'embêter avec des sémaphores complexes et leur compteur quand dans la plupart des cas on ne doit autoriser qu'un seul processus à la fois ? Plutôt qu'un sémaphore il vaut mieux mettre un mutex (mutual exclusion) qui, comme son nom l'indique, ne permet qu'à un seul processus d'accéder à la ressource. C'est ce qui a été fait à partir du noyau 2.6.16 et maintenant les seuls sémaphores qui restent dans le noyau sont (théoriquement) ceux pour lesquels il est vraiment indispensable d'avoir un compteur. Comme ils ne sont plus critiques pour les performances on peut remplacer tout leur code très optimisé écrit en assembleur pour chaque architecture par du code générique écrit en C. Le patch des sémaphores génériques écrit par Matthew Wilcox supprime donc plus de 7000 lignes de code complexe et les remplace par à peine 300 lignes (ce qui facilite grandement la lisibilité et la maintenabilité du noyau).
Le début du support des réseaux en maille (Mesh networking) fait son entrée dans le noyau. Ces réseaux se caractérisent par le fait que tous les hôtes sont connectés de proche en proche sans aucune hiérarchie centrale (plus de point d'accès privilégié au réseau donc). On se souvient que la possibilité de constitution de réseaux de ce type est une des grandes forces du projet One Laptop per Child. L'IEEE est en train de travailler sur la future norme 802.11s et c'est le second draft de cette future norme qui est implémenté dans la pile wifi mac80211 du noyau Linux. Le code est le résultat du travail du consortium Open80211s qui regroupe plusieurs entreprises afin de produire une implémentation libre de la norme 802.11s.
Actuellement l'implémentation est très préliminaire et seuls les pilotes b43 et zd1211rw sont capables de fonctionner en mode mesh. Si vous possédez une carte utilisant ces pilotes vous pouvez suivre ce howto et rapporter vos résultats sur la liste de diffusion linux-wireless.
Les périphériques PCI Express sont maintenant capables d'utiliser la fonction Active State Power Management (ASPM). Avec ASPM le lien PCI Express peut réduire sensiblement sa consommation de courant (au détriment toutefois de la latence pour repasser en mode performance maximum). Il est possible de choisir sa politique ASPM en passant des valeurs à /sys/module/pcie_aspm/parameters/policy. La valeur "default" s'en tient aux réglage par défaut du BIOS, la valeur "powersave" active toutes les fonctions d'économies d'énergie tandis que la valeur "performance" désactive ASPM au profit de la rapidité. Selon le message du commit la différence entre "powersave" et "performance" peut atteindre 1.3w dans un système contenant 3 liens PCI Express ce qui est loin d'être négligeable.
Concernant les disques durs traditionnels le système de fichiers Ext4 continue sa longue marche vers la stabilité afin de pouvoir sortir de son statut expérimental.
On peut noter que la technologie des barrières a été activée par défaut pour Ext4. Cette technologie améliore la fiabilité du système de fichiers en s'assurant que les données sont écrites dans le journal de façon cohérente avant que le disque ne puisse continuer son travail. L'ennui c'est que cette fonction qui existe aussi pour Ext3 n'est que rarement activée car l'impact sur les performances peut être sévère (Andrew Morton indique que la dernière fois que l'activation avait été tentée un ralentissement de 30% avait été observée sur certaines applications et qu'il avait donc rejeté le patch avec horreur). Ce ralentissement devrait être moins important avec Ext4 du fait de sa technologie et la fonction des barrières a donc été activée par défaut.
De manière générale le travail sur Ext4 avance de façon satisfaisante et Ted Ts'o, qui est le développeur principal, se sent maintenant assez confiant pour utiliser exclusivement Ext4 sur son ordinateur personnel. Quand on connaît sa minutie et son perfectionnisme on ne peut qu'être confiant sur la robustesse du nouveau système de fichiers.
Un support basique des lecteurs d'écran en braille a été intégré directement dans le noyau. Cet outil est très simple et ne peut se comparer aux lecteurs braille en espace utilisateur. Néanmoins cette fonction peut être très utile pour personnes déficientes visuelles en cas d'échec du boot ou si / ne peut pas être monté. Dans ces cas, le lecteur braille habituel (fonctionnant en mémoire utilisateur) ne peut pas être lancé et il est alors précieux d'avoir un support basique intégré au noyau. Une documentation est disponible et elle précise que le seul lecteur qui est pour l'instant supporté est VisioBraille.
L'outil intégré de virtualisation KVM fonctionne désormais sur les architectures IA64, PPC et S390 alors qu'auparavant il était limité aux x86 et x86-64.
Du côté de Xen, l'autre grande solution de virtualisation, le noyau 2.6.26 apporte la possibilité de faire varier dynamiquement la mémoire alloué aux domaines gérés par l'hôte. Ce "baloon driver" permet donc à l'hyperviseur Xen de distribuer la mémoire entre les domaines de façon plus souple. Une limitation existe toutefois puisque la quantité de mémoire du domaine ne peut actuellement qu'être réduite ou ré-augmentée jusqu'à la taille de départ. Un patch futur permettra d'augmenter la taille mémoire des domaines par rapport à leur taille initiale.
En bref....
- La fonction d'ordonnancement de groupe, introduite dans le noyau 2.6.24, voit ses fonctions de support du temps réel améliorées.
- Il est désormais possible de faire de la traduction d'adresse réseau (NAT) avec les protocoles UDP-Lite, DCCP et SCTP.
- Plusieurs patchs complètent le support de l'espace de noms pour les interfaces réseaux. C'est donc la continuation du long travail visant à masquer toutes les ressources globales du noyau (systèmes de fichiers, identifiants des processus, interfaces réseaux etc.) derrière une couche d'abstraction afin de pouvoir gérer des conteneurs séparés.
- La possibilité d'exécuter des binaires de SunOS et de Solaris a été supprimée. Le code était non maintenu et ne fonctionnait pas bien ce qui a provoqué le retrait de cette fonction (très peu utilisée).
- On peut maintenant attacher des périphériques IDE à chaud. Selon l'exemple donné dans la documentation pour changer le périphérique du port idex il suffit de faire un echo -n "1" > /sys/class/ide_port/idex/delete_devices puis d'enlever l'ancien périphérique et de brancher le nouveau en faisant un echo -n "1" > /sys/class/ide_port/idex/scan.
- Les processeurs de type Sun Niagara ont maintenant le support NUMA (Non Uniform Memory Access).
- Le noyau intègre maintenant divers pilotes spécifiques au portable Asus eeepc: le pilote global contrôle les hotkeys, le réseau et la caméra; le pilote écran s'occupe du rétroéclairage et le pilote hardware contrôle le ventilateur.
La liste détaillant toutes les autres nouveautés (réseaux, systèmes de fichier, pilotes disques, cartes son, vidéo, Bluetooth, etc.) est comme d'habiture disponible sur le site de Kernelnewbies.

Pour un bilan sous forme de statistiques le noyau 2.6.26 aura incorporé plus de 10100 patchs venant d'environ 1065 développeurs. Le nombre de lignes de code ajoutées dans le noyau dépasse les 169000.
À titre indicatif voici le nombre de patchs intégrés pour les sept derniers noyaux :
2.6.20 => 4983 patchs
2.6.21 => 5349 patchs
2.6.22 => 6648 patchs
2.6.23 => 7075 patchs
2.6.24 => 10353 patchs
2.6.25 => 12707 patchs
2.6.26 => 10132 patchs

Sachant que l'intervalle entre chaque noyau est de moins de trois mois on constate que le rythme de développement reste très soutenu et que le monde du libre n'a pas à s'inquiéter d'une éventuelle stagnation de Linux.

Pour le futur....

Comme d'habitude la page spécifique maintenue par Jonathan Corbet est un atout précieux pour avoir une idée les développements à venir dans le noyau Linux. Néanmoins, le travail de prévision est rendu bien plus précis cette fois-ci par l'arrivée de la nouvelle branche linux-next maintenue par Stephen Rothwell. Cette branche est destinée à jouer un rôle de "tampon" entre la très expérimentale branche -mm d'Andrew Morton et la première release candidate de Linus. Tous les patchs du futur noyau 2.6.27 ont donc déjà migré dans la branche linux-next afin que les problèmes de conflits de code puissent être résolus le plus tôt possible. Un article du site LWN fait le point sur cette branche et explique bien le long cycle de développement du nouveau code : Dépôt privé du développeur -> Branche expérimentale -mm -> Branche linux-next -> Versions release-candidate -> Noyau Linux officiel -> Branches -stable -> Intégration dans les distributions.
Pour savoir ce qui va rentrer dans le noyau 2.6.27 jetons donc un coup d'oeil rapide sur linux-next :

Comme il était annoncé dans cette dépêche un grand nombre de patchs supprimant des appels au verrou global du noyau sont d'ores et déjà programmés pour inclusion. Le travail est cependant loin d'être fini et l'éradication du verrou global va sans doute s'étaler sur plusieurs mois.
Une grande réorganisation du répertoire arch/ppc est prévue avec la suppression d'une grande partie du code au profit d'une organisation plus générique.
Le système de fichiers UBIFS qui est spécialisé pour les disques SSD fait l'objet d'une revue de code à la demande des ingénieurs de Nokia pour une future inclusion dans le noyau. Comme le résultat semble positif il est presque certain qu'UBIFS va intégrer le 2.6.27.
L'outil ftrace permettant de suivre les appels système d'une commande donnée en paramètre est programmé pour faire son entrée et va améliorer les possibilités offertes pour contrôler le fonctionnement du noyau.
Enfin un mot au sujet des autres outils de tracing utrace et SystemTap qui continuent de se faire désirer. Il subsiste des problèmes techniques qui empêchent l'inclusion d'utrace dans la branche principale de Linux et cela bloque donc également l'entrée d'une partie des fonctionnalités de SystemTap. L'aiguillon que constitue le "concurrent" DTrace est cependant une motivation puissante pour les développeurs de SystemTap afin de résoudre ces problèmes. Tout le monde est bien conscient de cette concurrence et une longue discussion à ce sujet a eu lieu sur la liste de diffusion des sommets du noyau Linux. Selon l'un des développeurs de SystemTap une partie de la facilité d'utilisation de DTrace vient du fait que le noyau Solaris de Sun ne change pas beaucoup et qu'il pratique une stricte politique de compatibilité binaire (ABI). Le noyau Linux se développe à une vitesse sans commune mesure et a en plus choisi de ne pas rester prisonnier ad vitam aeternam d'une compatibilité binaire. Selon lui il est donc normal que le noyau Linux doive payer le prix de son succès par une implémentation plus difficile des outils de tracing.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

stats

Posté par baud123 (Jabber id, page perso, ) le 14/07/2008 à 11:30. (lien). Évalué à 8.

moi j'aime bien les stats de Linus, il en a encore ajouté lors de l'annonce officielle d'hier : http://lkml.org/lkml/2008/7/13/216 (et http://kernel.org/ est maintenant à jour avec cette dernière version).

[^]Re: stats

Posté par Matthieu Lagouge (Jabber id, page perso, ) le 14/07/2008 à 13:09. (lien). Évalué à 10.
Moi c'est les dépêches de patrick_g que j'aime bien!

Bravo encore une fois à patrick_g!
Que saurais-je de ce qui change dans mes kernels sans toi?!
- [^]Re: stats
  
  Posté par vincentxs () le 14/07/2008 à 18:38. (lien). Évalué à 7.
  tu peux toujours le lire en version native ici:
  
  http://kernelnewbies.org/Linux_2_6_26

Mini correction

Posté par Kerro () le 14/07/2008 à 12:11. (lien). Évalué à 3.

Je ne l'ai jamais fait, il faut un début: chapeau pour cet dépêche !

Il est désormais possible de faire de la translation d'adresse réseau (NAT)
--> traduction d'adresse(s)

[^]Re: Mini correction

Posté par TNorth () le 14/07/2008 à 13:15. (lien). Évalué à 3.
bind --mount /mnt/sda1 /mon_conteneur/plop"
serait

mount --bind /mnt/sda1 /mon_conteneur/plop
- [^]Re: Mini correction
  
  Posté par TNorth () le 14/07/2008 à 13:17. (lien). Évalué à 1.
  Arg grillé, j'ai pas fait de refresh entre le début de la lecture de la news et le commentaire envoyé :/

[^]Re: Mini correction

Posté par NickNolte () le 14/07/2008 à 18:03. (lien). Évalué à 1.
Je trouve au contraire que "translation" colle bien au context.
Les connexions réseaux induisant une idée de "mouvement"/"déplacement" et connaissant le concept de NAT, la pertinence de ce choix me semble evident ou tout au moins pas choquant.
- [^]Re: Mini correction
  
  Posté par Kerro () le 14/07/2008 à 23:12. (lien). Évalué à 10.
  colle bien au context
  Ca s'écrit "contexte" chez nous.
  
  Et pour "translation" ça s'écrit "traduction" chez nous.
  
  Translation est utilisé pour décrire un déplacement... mais c'est surtout copié/collé depuis le mot anglais. Le NAT ne fait pas de translation. Il translate quoi ? Il déplace quoi ? Il décale les adresses ? --> il associe une adresse+port à un port.
  Le terme "traduction" n'est pas parfait, mais moins mauvais. Je ne sais pas par quoi le remplacer, alors je garde la traduction de "translation" qui est "traduction" (aîe le jeu de mot nul). Peut-être "transfomation". De toutes manières, maintenant que tout le monde utilise "translation", même pas la peine de chercher quelque chose de mieux :-)
  
  Le NAT est, textuellement: traduction d'adresse(s) réseau.
  Et en principe c'est plutôt NATP. Le 'P' étant là pour "Protocol". Je ne vois pas le pourquoi de "protocole" car il n'y a aucun protocole. Entre quoi et quoi ? C'est UN programme qui s'en occupe. Il discute tout seul. Ce n'est pas un protocole, c'est une méthode.
  - [^]Re: Mini correction
    
    Posté par NickNolte () le 15/07/2008 à 00:18. (lien). Évalué à 10.
    Ca s'écrit "contexte" chez nous.
    Ça s'écrit "ça" chez nous.
  - [^]Re: Mini correction
    
    Posté par Nicolas Legrand () le 15/07/2008 à 10:55. (lien). Évalué à 4.
    Ça s'appelle enculer les mouches chez moi. :-)
    - [^]Re: Mini correction
      
      Posté par Hugues (page perso, ) le 24/07/2008 à 17:45. (lien). Évalué à 1.
      Ça s'appelle enculer les mouches chez moi. :-)
      
      T'en as une toute petite, ou tu utilises beaucoup de chatterton ?
      
      Poussez-pas...
      
      --
      A l'âge de bière, les hommes vivaient dans les tavernes.
  - [^]Re: Mini correction
    
    Posté par e-t172 (page perso, ) le 15/07/2008 à 12:03. (lien). Évalué à 3.
    Le NAT ne fait pas de translation. Il translate quoi ? Il déplace quoi ? Il décale les adresses ? --> il associe une adresse+port à un port.
    
    Non, ça c'est du Masquerading, qui est une forme particulière de NAT. Un NAT au sens strict, ça traduit simplement une adresse IP en une autre, sans s'occuper du port.
    - [^]Re: Mini correction
      
      Posté par reno () le 15/07/2008 à 12:47. (lien). Évalué à 3.
      Non, une 'adresse' est a prendre au sens large: au niveau TCP et UDP, c'est l'adresse IP + le port.
      
      Netfilter ne permet même pas de changer l'adresse IP sans changer le port (ce qui est très bete car c'est utile parfois!).
      - [^]Re: Mini correction
        
        Posté par rouby () le 18/07/2008 à 08:25. (lien). Évalué à 2.
        ???
        Dans quel sens doit-on interpréter ta phrase?
        En DNAT, c'est faux.
        En SNAT, c'est peut-être vrai et sûrement nécessaire dans certains.
- [^]Re: Mini correction
  
  Posté par Kerro () le 14/07/2008 à 23:19. (lien). Évalué à 2.
  J'avoue qu'en NAT pur, "translation" est tout de même pas mal...
  A la réflexion :-)
  
  D'ailleurs, qui a déjà utilisé du NAT (et pas du NAT dynamique comme sur les modems/routeurs) ? Je vois bien ce que c'est, mais je n'en vois pas plus que ça l'intérêt. Peut-être suite à la fusion de deux réseaux ayant malheureusement les mêmes plages d'adresses ?
  - [^]Re: Mini correction
    
    Posté par kowalsky () le 15/07/2008 à 09:36. (lien). Évalué à 3.
    ça sert dans le cas de réseau qui ont la même adresse, ou pour l'inclusion d'un réseau dans un "grand" réseau, pour une maitrise de l'adresse quoi.
    
    Et il ne faut pas confondre le NAT et PAT.
    
    Le PAT est celui utilisé dans les modems/routeurs, il joue avec les ports pour faire que plusieurs adresse puisse sortir du réseau en même temps. Par contre, une seul adresse est visible depuis l'extérieur, et il faut "rediriger" les ports voulu sur l'adresse choisit.
    
    --
    You got the money, I got the soul.

[^]Re: Mini correction

Posté par jihele () le 15/07/2008 à 09:03. (lien). Évalué à 1.
la travail sur le noyau Linux augmente d'année en année

[^]Re: Mini correction

Posté par jon207 (Jabber id, page perso, ) le 16/07/2008 à 10:42. (lien). Évalué à 1.
Pour continuer dans la sodomie des mouches :
"un ralentissement de 30% avait été observée". C'est trois fois rien mais la déphe est tellement parfaite que le moindre petit détail se remarque.

Sinon excellente dépêche comme d'hab. /me se demande si patrick_g arrive à avoir une vie en plus d'écrire ses dépêches.

--
"La liberté ne peut être que toute la liberté ; un morceau de liberté n’est pas la liberté." -- Max Stirner

bind mount ?

Posté par FreeB5D () le 14/07/2008 à 13:08. (lien). Évalué à 1.

"Le noyau 2.6.26 corrige une faiblesse sur la fonction mount --bind. Cette fonction permet très facilement de monter une arborescence sur un second point de montage. Si par exemple j'ai un disque dur qui se trouve dans "/mnt/sda1" et que je veux le mettre aussi dans "/mon_conteneur/plop", je dois créer le dossier de destination et lancer la commande "bind --mount /mnt/sda1 /mon_conteneur/plop". On peut par exemple utiliser le bind mount pour exporter une arborescence dans un conteneur."
C'est bind --mount ou mount --bind ?

--
Linux çapu, mais quand Windows est concerné Linux c'est génial .

[^]Re: bind mount ?

Posté par Vivien Moreau (Jabber id, ) le 14/07/2008 à 13:15. (lien). Évalué à 3.
Oui, y'a une erreur de frappe, ça devrait bien être mount --bind :-)

--
Sous GNU/Linux depuis déjà plus de deux ans, ça passe vite :-)
- [^]Re: bind mount ?
  
  Posté par Sylvain Rampacek (Jabber id, page perso, ) le 14/07/2008 à 13:58. (lien). Évalué à 2.
  c'est corrigé ;-)
  merci !

Belle dépêche

Posté par polytan () le 14/07/2008 à 13:10. (lien). Évalué à 1.

Très belle dépêche, cela se lit avec plaisir du début à la fin?

Merci Patrick !

[^]Re: Belle dépêche

Posté par polytan () le 14/07/2008 à 13:24. (lien). Évalué à 2.
s/?/. ...
- [^]Re: Belle dépêche
  
  Posté par Thomas Preud'homme (Jabber id, ) le 14/07/2008 à 16:22. (lien). Évalué à 0.
  Du pur patrick_g comme d'habitude. Clair et complet.
  
  Merci patrick_g
  
  --
  Don't run, we are your friends : IFM (http://intergalacticfm.com)

Tuxonice

Posté par jll_ (Jabber id, ) le 14/07/2008 à 13:33. (lien). Évalué à 1.

Comme pour la new sur le 2.6.25, on peux trouver tuxonice pour la version 2.6.26 ici:
http://user.it.uu.se/~mikpe/linux/patches/tuxonice/

Les bits de sécurité ?

Posté par Ph Husson (Jabber id, ) le 14/07/2008 à 15:50. (lien). Évalué à 2.

Le patch implémentant la notion de bit de sécurité par processus a été ajouté au noyau 2.6.26

Un avantage de Hurd sur linux en moins ! (les spécialistes me corrigeront si je me trompe, mais je crois que ca correspond au principe de tokens du hurd)

--
Ce messages est crypté par le système 42-rot13 pour plus de sécurité.

[^]Re: Les bits de sécurité ?

Posté par Xavier Claude () le 14/07/2008 à 16:34. (lien). Évalué à 4.
Est-ce que quelqu'un pourrait réexpliquer ce que c'est et à quoi ça sert parce que j'ai pas bien compris?

--
Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. (R. Devos)
- [^]Re: Les bits de sécurité ?
  
  Posté par Stone Tramo () le 14/07/2008 à 16:55. (lien). Évalué à 10.
  Le hurd? A rien.
  - [^]Re: Les bits de sécurité ?
    
    Posté par Xavier Claude () le 14/07/2008 à 17:34. (lien). Évalué à 5.
    les bits de sécurité
    
    --
    Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. (R. Devos)
    - [^]Re: Les bits de sécurité ?
      
      Posté par v_atekor () le 14/07/2008 à 17:55. (lien). Évalué à 7.
      Hurd ne sert à rien :O
      Hurd servira à faire tourner Duke Nukem Forever ! [Et avec les bits de sécurité, s'il te plait! ]
      
      Mais je veux bien une explication aussi sur les bits de sécurité ?
      - [^]Re: Les bits de sécurité ?
        
        Posté par bilboa () le 14/07/2008 à 18:14. (lien). Évalué à 6.
        ce qu'ils veulent dire c'est que tu peut avoir des CAP(abilities) par processus, comme avec www.rsbac.org (module CAP).
        
        Sinon c'était le root qui avait toutes les CAP uniquement.
        
        Par ex ping a besoin la cap NET RAW, donc il est setuid root. si le processus peut être assigné le bit de cap pour net raw, plus besoin de setuid root.
        
        Enfin si je me trompe pas dans ce qu'ils veulent dire par bit de securité.
- [^]Re: Les bits de sécurité ?
  
  Posté par Ph Husson (Jabber id, ) le 14/07/2008 à 21:06. (lien). Évalué à 10.
  Bon alors je me suis un peu informé en cours de route et il s'avere que je me trompe un peu (enfin toujours si j'ai bien tout compris).
  Donc en fait, avant chaque utilisateur avait ses "capabilities" (ce qu'il a le droit de faire en fait), comme pouvoir lancer des serveurs sur des ports < 1024, acceder aux interfaces réseau en raw, etc. Enfin en théorie du moins, en pratique, meme si linux etait censé le gérer, rien n'était vraiment fait pour et ca tenait du capharnaum, et c'etait par utilisateur.
  La nouveauté ici c'est, en fait, qu'un processus peut modifier ses propres capabilities (et ceux de ses déscendants, à coup de fork() et exec() ), par contre, contrairement au hurd un processus ayant tous les droits ne peut pas ('fin de ce que j'ai lu, a priori en espace noyau ca a pas l'air bien compliqué à faire) donner ses droits à un autre processus.
  En tout cas, cette amélioration est un gain nette en terme de sécurité:
  Prenons le cas d'un serveur http qui écoute sur le port 80. Il n'a, a priori, aucune raison d'avoir de droits particuliers, sauf pour le port (pour les ports < 1024 faut avoir une "capability" qui va bien). Et donc jusqu'à aujourd'hui, il fallait lancer apache en root, qui apres avoir lancé la partie écoute du port 80, se mettait sous l'utilisateur apache, mais une faille de sécurité peut encore exister entrtre le lancement de l'écoute et le changement d'utilisateur !
  Maintenant on pourra lancer apache directement sous l'utilisateur apache, avec le droit de lancer un serveur sur le port 80, donc on pourra inclure dans sysvinit un utilitaire de la forme launch_w_caps apache BIND_INF_1024 httpd, qui lancera httpd sous l'utilisateur apache directement, tout en lui gardant le droit de lancer un serveur sur le port 80 (et donc si y a une faille de sécu, elle pourra etre partagée entre tous les serveurs :) )
  
  --
  Ce messages est crypté par le système 42-rot13 pour plus de sécurité.
  - [^]Re: Les bits de sécurité ?
    
    Posté par Kerro () le 14/07/2008 à 23:23. (lien). Évalué à 2.
    <mode troll>
    Ah ouais, c'est un truc qui existe depuis longtemps chez OpenBSD ça :-) (et peut-être les autres BSD, je ne sais plus. Jamais utilisé)
    </mode troll>
    - [^]Re: Les bits de sécurité ?
      
      Posté par Fabien (page perso, ) le 15/07/2008 à 15:23. (lien). Évalué à 2.
      bizarre, il me semble que j'utilise déjà tout ça avec linux et depuis bien longtemps .....
      merci grsecurity
  - [^]Re: Les bits de sécurité ?
    
    Posté par ribwund () le 17/07/2008 à 13:38. (lien). Évalué à 2.
    Il y a aussi l'idée de mettre les capabilities sur le fichier (une sorte de setuid à grain fin).

errata

Posté par Matthieu C () le 14/07/2008 à 18:05. (lien). Évalué à 7.

Pour cela les sémaphores embarquent un compteur mais pourtant dans la pratique la limite est presque toujours fixée à 1 (un seul processus doit avoir accès à la ressource à un moment donné). Pourquoi alors s'embêter avec des sémaphores complexes et leur compteur quand dans la plupart des cas on ne doit autoriser qu'un seul processus à la fois ?
Parce que dans un mutex c'est le même thread qui fait le lock/unlock alors que ce n'est pas le cas avec les sémaphore.

Le système de fichiers UBIFS qui est spécialisé pour les disques SSD fait l'objet d'une revue de code à la demande des ingénieurs de Nokia pour une future inclusion dans le noyau. Comme le résultat semble positif il est presque certain qu'UBIFS va intégrer le 2.6.27.
UBIFS est pour les flash accéder via mtd, pas pour les disques SSD qui émule en hard une interface de type disque dur standard.

On peut maintenant attacher des périphériques IDE à chaud. Selon l'exemple donné dans la documentation pour changer le périphérique du port idex il suffit de faire un echo -n "1" > /sys/class/ide_port/idex/delete_devices puis d'enlever l'ancien périphérique et de brancher le nouveau en faisant un echo -n "1" > /sys/class/ide_port/idex/scan.
C'était pas déjà le cas en utilisant la nouvelle stack pata s'appuyant sur libata ?

[^]Re: errata

Posté par neologix (page perso, ) le 14/07/2008 à 22:58. (lien). Évalué à 3.
Parce que dans un mutex c'est le même thread qui fait le lock/unlock alors que ce n'est pas le cas avec les sémaphore.

C'est vrai que c'est vachement intéressant un méchanisme de synchronisation dans le cas où les sections critiques ne peuvent être exécutées que par un seul thread...
- [^]Re: errata
  
  Posté par loufoque () le 20/07/2008 à 19:43. (lien). Évalué à 3.
  Ça n'a rien à voir.
  Avec des mutexes read/write ou avec rcu, tu peux exécuter du code par plusieurs threads en même temps et pourtant le verrou doit bien être libéré par celui qui l'a acquis.

Virtualisation?

Posté par ethtezahl () le 14/07/2008 à 19:43. (lien). Évalué à 0.

Est ce que linux-vserver est intégré par défaut au noyau?

--
http://ethtezahl.over-blog.com/

http://www.grattadom.com

[^]Re: Virtualisation?

Posté par Aefron () le 14/07/2008 à 23:25. (lien). Évalué à 5.
A priori, les efforts se concentrent sur l'ajout dans le noyau de patches pouvant génériquement servir aux solutions de virtualisation/conteneurs, plutôt que l'intégration de solutions complètes, pour l'instant...

... une solution complète sera probablement intégrée à terme, mais pour l'instant, comme le dit patrick_g, l'heure est à un "long travail visant à masquer toutes les ressources globales du noyau (systèmes de fichiers, identifiants des processus, interfaces réseaux etc.) derrière une couche d'abstraction afin de pouvoir gérer des conteneurs séparés".

Chacun y vient petit à petit, comme chez FreeBSD, avec la virtualisation de la pile réseau [1]

D'ailleurs, à ce titre, les développeurs de solutions de conteneurs participent à patcher le noyau petit à petit, en tout cas, chez OpenVZ [2] (j'imagine qu'ils le font aussi chez VServer), que je découvre après 6 mois de VServer, que je trouvais déjà très bien, mais qui est bien moins polyvalent au niveau réseau :

- VServer isole des interfaces de l'hôte, en les faisant discuter via le loopback, ce qui empêche de laisser le loopback grand ouvert, si on veut firewaller entre les conteneurs, et ce qui empêche aussi d'avoir un loopback dans le conteneur (on est forcé de rechercher toutes les occurences de 127.0.0.1 et de les remplacer par du localhost, qu'on a manuellement fait correspondre à l'adresse IP du conteneur... voire de forcer manuellement les services sur cette adresse)...

- OpenVZ virtualise le dialogue réseau en faisant intervenir une interface virtuelle qui permet de réaliser le routage entre les conteneurs, qui disposent donc d'un loopback à eux... a priori, ils sont chacun sur un /32 en point à point avec l'interface virtuelle, mais on peut leur donner un peu plus de capacités, pour qu'ils aient leurs propres iptables, routes, qu'on puisse les bridger avec le reste, par exemple pour mettre une sonde d'IDS en promiscuous, qu'ils puissent avoir du broadcast, et même qu'ils gèrent une interface réseau physique, sans que l'hôte n'y ait accès, voire même, qu'ils aillent jusqu'à router eux-aussi...

... sur ce point OpenVZ roxorise des famille-ours ! Dommage que le kernel binaire et l'outil de migration (enfin, ça, encore... faut avoir assez de machines, pour ça... mais c'est assez classe à voir [3]) ne soient pas directement packagés dans Debian... et que le miroir des kernels fza soit dans un composant "openvz" bizarre (et pas dans un "main"), ce qui fait qu'on ne peut pas l'inclure via debian-cd/simple-cdd...

En tout cas, si on n'a pas besoin de faire tourner plusieurs kernels, les conteneurs, c'est génial.

[1] http://imunes.tel.fer.hr/virtnet/
[2] http://community.livejournal.com/openvz/22369.html
[3] http://www.montanalinux.org/openvz-live-migration-demo.html
- [^]Re: Virtualisation?
  
  Posté par ginkyo (page perso, ) le 15/07/2008 à 12:51. (lien). Évalué à 3.
  au besoin :
  
  + sources.list
  # Open-vz (debian.systs.org - a private debian repository of Thorsten Schifferdecker)
  deb http://debian.systs.org/ stable openvz
  
  + Deux modèles réseau sont proposés pour le système OpenVZ
  http://wiki.openvz.org/Differences_between_venet_and_veth
  
  Bien à vous
  
  --
  « Si quis scienter in tantum a vino abstineret ut naturam multum gravaret a culpa immunis non esset. »Saint Thomas d'Aquin, Somme théologique, II-II, 150, 1 ad 1.
  - [^]Re: Virtualisation?
    
    Posté par kaouete (page perso, ) le 15/07/2008 à 12:57. (lien). Évalué à 3.
    Et d'après un des maintener debian du kernel, openvz y sera bientôt packagé :
    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489387#10
    - [^]Re: Virtualisation?
      
      Posté par Aefron () le 15/07/2008 à 17:20. (lien). Évalué à 3.
      Ca, ce serait vraiment excellent ! Par contre, j'imagine que c'est peut-être un peu tard pour Lenny, s'il est toujours prévu qu'il doive sortir au début de l'automne...
      - [^]Re: Virtualisation?
        
        Posté par dab () le 15/07/2008 à 20:05. (lien). Évalué à 3.
        Lenny semble être toujours prévue pour Septembre.
        http://wiki.debian.org/DebianLenny
        http://lists.debian.org/debian-devel-announce/2008/06/msg000(...)
        
        [^]Re: Virtualisation?
        
        Posté par Aefron () le 16/07/2008 à 03:23. (lien). Évalué à 2.
        De toute façon, ce sera prêt quand ce sera prêt :) ... enfin, si ça pouvait éviter d'avoir plus de 5 mois de bourre, ce ne serait certes pas plus mal...
        
        ... et si le kernel 2.6.26 pouvait y trouver sa voie, histoire d'avoir du bind mount (d'une utilité remarquable, avec les conteneurs) en lecture seule, ce serait déjà très bien.
  - [^]Re: Virtualisation?
    
    Posté par Aefron () le 15/07/2008 à 17:17. (lien). Évalué à 2.
    Pour le sources.list, oui, je le connais (le wiki d'OpenVZ est d'ailleurs très bien)...
    
    Le souci, c'est que je voulais me faire un CD d'installation customisé de Debian qui m'installe déjà tout ce qu'il me faut, y compris le kernel et les utilitaires packagés par Thorsten...
    
    ... or debian-cd/simple-cdd ne gèrent que les composants main, contrib, et non-free (c'est hardcodé dans debian-cd : pas le choix)... et du coup, le composant openvz, bah, pas moyen de l'inclure comme ça...
    
    Je pourrais faire avec FAI, mais je ne le connais pas bien, il n'est à la base pas prévu pour faire de CD (même si je sais très bien que ça se fait), et surtout, il n'est pas spécialement prévu pour l'interactivité (je veux au moins choisir mes paramètres réseau, et le HDD à formater... plus quelques autres binioucs, si je me mets à packager des conteneurs pour les installer)... Je pourrais aussi télécharger les .deb à la mimine, mais je perdrais par exemple l'avantage d'installer directement linux-image-openvz-2.6-686, et il faudrait mettre la référence exacte de la révision du kernel à la main...
    
    Du coup, je vais pour l'instant au plus simple, et je pars plutôt sur http://download.openvz.org/debian (seulement du kernel, et pas avec le fichier de config Debian, comme les fza de Thorsten... l'enfin, pour le moment, tant pis) que vers http://download.openvz.org/debian-systs (qui est un miroir de celui que tu donnes, par les gars de chez OpenVZ)... d'autant que j'ai essayé de trouver une adresse mail pour joindre Thorsten, et je me suis même inscrit sur le forum OpenVZ pour lui envoyer un message privé : en vain ; il ne les accepte pas... bon, j'ai quand même fini par trouver son mail en fouillant un peu : faudra que je pense à le contacter... En attendant, mon CD d'installation d'une Debian OpenVZée marche bien quand même.

dire

Posté par dark_star () le 14/07/2008 à 20:32. (lien). Évalué à 4.

que l'on a tous cela dans notre ordi à la maison ! cela fait peur !

sinon pour le systeme de fichier de nokia, cela fait toujours plaisir de voir une demande de ce genre.

je me disais avec les nouvelles stats que le devellopement de linux est vraiment important. Et avec les net pc qui sorte sous linux, en plus. il auras fallu attendre presque 15 ans pour avoir le succés

bref cela fait plaisir

PAT c'est surtout pour WC, pas pour les caches

Posté par Brice Goglin () le 15/07/2008 à 08:34. (lien). Évalué à 8.

Le support de PAT n'a pas été demandé pour gérer le cache, pas plutôt pour les drivers réseau et graphiques qui voulaient faire du PIO rapide grâce au Write-Combining (WC, qui regroupe des écritures contigues en mémoire en une seule grosse écriture sur le bus). Pour le cache, les MTRR suffisaient très souvent car la répartition cachable/uncachable est souvent très simple (une grande zone de RAM cachable suivie d'une grande zone de mémoire I/O uncachable).

Par contre, quand on commence à mettre du WC sur les cartes réseau et graphique, le nombre de plage à configurer dépasse rapidement le nombre de MTRR disponible (4 ou 8), d'où l'intérêt de PAT. Surtout que c'était disponible depuis longtemps dans les autres OS et que Linux continuait à ne pas le supporter avec des prétextes douteux pour refuser des patchs.

Par contre, le support de PAT n'est encore satisfaisant dans 2.6.26. Par exemple, quand on demande du WC, on a aucune garantie de l'avoir, on peut avoir du uncachable habituel. Mais pire, on n'est pas prévenu quand ca arrive (notamment quand PAT est désactivé, ce qui est le cas par défaut dans 2.6.26).

Et encore pire, comme PAT est prioritaire sur MTRR, on ne peut pas mettre un MTRR en plus "au cas où" car il sera ignoré à cause de PAT. Donc au final, PAT devient une solution de secours pour les drivers, alors que ca devait être la solution ultime. On va devoir essayer de mettre une MTRR WC d'abord, et si ca foire, on demandera du PAT WC en espérant ne pas avoir du uncachable à la place. Super...

[^]Re: PAT c'est surtout pour WC, pas pour les caches

Posté par Brice Goglin () le 15/07/2008 à 08:46. (lien). Évalué à 1.
s/pas plutot/mais plutot/ en premiere ligne...

[^]Re: PAT c'est surtout pour WC, pas pour les caches

Posté par Mathieu Stumpf (Jabber id, page perso, ) le 15/07/2008 à 10:03. (lien). Évalué à 1.
Ton commentaire est intéressant mais je trouve les termes "cachable" et "uncachable" mauvais. J'aurais dit «que l'on peu on non mettre en mémoire cache».

À part ça merci pour cette précision. :)

--
Le wiki de l'association culture libre : venez participer !
- [^]Re: PAT c'est surtout pour WC, pas pour les caches
  
  Posté par Brice Goglin () le 15/07/2008 à 11:27. (lien). Évalué à 5.
  En fait, c'était des termes anglais sans même avoir vaguement songé à essayer de les traduire :) Je préfère coller à ce qu'on trouve dans ton /proc/mtrr ("uncachable") plutôt que d'essayer de traduire (pas la peine de lancer un troll sur est-ce que le mot cache est français :))

[^]Re: PAT c'est surtout pour WC, pas pour les caches

Posté par Matthieu Lagouge (Jabber id, page perso, ) le 17/07/2008 à 15:46. (lien). Évalué à 7.
Ca fait des ravages la fatigue:

En lisant le titre de ton commentaire, j'ai cru que tu voulais envoyer Patrick aux chiottes. Me suis dit "'Tain il est vachement provoc, lui, il va mourir c'est sûr!"

Pis après j'ai compris que tu parlais d'un truc que je comprends pas, et ça me déprime de me rendre compte que ça m'a rassuré...

Sur ce, bonne nuit! ----> [ ]

UVC

Posté par Richard Genoud () le 16/07/2008 à 13:18. (lien). Évalué à 10.

Comme "nouveauté", il y a aussi l'UVC.
Ca existait depuis pas mal de temps en dehors du noyau, mais quelques distributions l'intégraient déjà.
Donc, pour l'utilisateur final, aucune différence.
C'est simplement que l'évolution de ce driver se fera dans de meilleures conditions.

[proud mode]
bon, y a aussi mon patch qui a été accepté dans ce noyau...
NAND: Hardware ECC controller on at91sam9263 / at91sam9260
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)
Une fierté personnelle...
[/proud mode]

expérience avec les pilotes Radeon ?

Posté par Jetto () le 19/07/2008 à 17:45. (lien). Évalué à 2.

Merci Monsieur patrick_g pour cet excellent article (et aussi pour les autres qui sont aussi bon qu'indispensable au moins pour ceux qui ne sont pas fluent en anglais). C'est un peu bateau comme entrée en matière mais c'est ici un cas de force majeur vu la qualité des articles de Monsieur patrick_g.

Y a t-il quelqu'un qui a déjà tester les pilotes Radeon ? Il se trouve que j'ai une X1600 pro AGP avec 512Mo et que le pilote propriétaire ne fonctionnent plus avec ma carte depuis sons passage en version 8.x (c'est un bug) et donc je ne peux plus upgrader mon noyau.

Je me demande donc si j'ai des chances que ma carte (RV530) fonctionne correctement avec la dernière version du noyau.

En attendant un réponse je me commencer à chercher sérieusement ce qu'il faut pour que ça marche.

[^]Re: expérience avec les pilotes Radeon ?

Posté par Mjules (page perso, ) le 19/07/2008 à 19:04. (lien). Évalué à 1.
la partie DRM des R500 a été incluse dans ce noyau. Après, les derniers pilotes ATI doivent pouvoir la faire fonctionner en 2D.
Pour la 3D, je ne sais pas si des pilotes sont déjà sortis mais je ne crois pas, il va falloir compiler MESA toi même AMHA.
- [^]Re: expérience avec les pilotes Radeon ?
  
  Posté par Jetto () le 19/07/2008 à 19:42. (lien). Évalué à 2.
  Oui sur la page radeonhd:DRI (http://wiki.x.org/wiki/radeonhd%3ADRI ) on lit qu'il y a un peut de travail pour pouvoir profiter du DRI et qu'il n'y a pas de support simultané de l'accélération 2D et 3D.
  
  Je trouve quand même que ça progresse plutôt vite. La dernière version du pilote xorg remonte à 3 mois pourtant il y a des commit réguliers.
  - [^]Re: expérience avec les pilotes Radeon ?
    
    Posté par Brice Goglin () le 24/07/2008 à 00:08. (lien). Évalué à 1.
    <troll>
    Laissez tomber le driver radeonhd, xf86-video-ati est mieux et mieux supporté
    </troll>
- [^]Re: expérience avec les pilotes Radeon ?
  
  Posté par Brice Goglin () le 24/07/2008 à 00:11. (lien). Évalué à 1.
  Avec une distribution correcte, tu auras des paquets précompilés des release candidates de Mesa 7.1 qui contiennent le driver 3d pour r500. Genre il y a Mesa 7.1-rc3 dans Debian experimental.

Revenir en haut de page

Articles précédents : Logiciel

Liens connexes

Dépêche modérée par

Dépêche éditée par

Logiciel : Sortie du noyau Linux 2.6.26

stats

[^]Re: stats

[^]Re: stats

Mini correction

[^]Re: Mini correction

[^]Re: Mini correction

[^]Re: Mini correction

[^]Re: Mini correction

[^]Re: Mini correction

[^]Re: Mini correction

[^]Re: Mini correction

[^]Re: Mini correction

[^]Re: Mini correction

[^]Re: Mini correction

[^]Re: Mini correction

[^]Re: Mini correction

[^]Re: Mini correction

[^]Re: Mini correction

bind mount ?

[^]Re: bind mount ?

[^]Re: bind mount ?

Belle dépêche

[^]Re: Belle dépêche

[^]Re: Belle dépêche

Tuxonice

Les bits de sécurité ?

[^]Re: Les bits de sécurité ?

[^]Re: Les bits de sécurité ?

[^]Re: Les bits de sécurité ?

[^]Re: Les bits de sécurité ?

[^]Re: Les bits de sécurité ?

[^]Re: Les bits de sécurité ?

[^]Re: Les bits de sécurité ?

[^]Re: Les bits de sécurité ?

[^]Re: Les bits de sécurité ?

errata

[^]Re: errata

[^]Re: errata

Virtualisation?

[^]Re: Virtualisation?

[^]Re: Virtualisation?

[^]Re: Virtualisation?

[^]Re: Virtualisation?

[^]Re: Virtualisation?

[^]Re: Virtualisation?

[^]Re: Virtualisation?

dire

PAT c'est surtout pour WC, pas pour les caches

[^]Re: PAT c'est surtout pour WC, pas pour les caches

[^]Re: PAT c'est surtout pour WC, pas pour les caches

[^]Re: PAT c'est surtout pour WC, pas pour les caches

[^]Re: PAT c'est surtout pour WC, pas pour les caches

UVC

expérience avec les pilotes Radeon ?

[^]Re: expérience avec les pilotes Radeon ?

[^]Re: expérience avec les pilotes Radeon ?

[^]Re: expérience avec les pilotes Radeon ?

[^]Re: expérience avec les pilotes Radeon ?