jeudi 21 août
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

: Nouvelle version 2.6.19 du noyau Linux

Posté par patrick_g (page perso, ). Modéré le 30 novembre 2006.
Un peu plus de deux mois après la version précédente Linus Torvalds a annoncé la version 2.6.19 du noyau Linux. Il y a beaucoup de nouvelles choses et le nombre de changements est plus élevé qu'à l'ordinaire. Cela s'explique par le fait que la gestation du noyau précédent (2.6.18) a été longue : Linus a été en voyage ce qui a ralenti la sortie des versions candidates (RC) et cela a mécaniquement allongé la période de développement des patchs devant intégrer le noyau suivant (le 2.6.19).

Le résultat ?
Bien plus de 5000 patchs venant de plus de 600 contributeurs différents ! Et ces statistiques valent uniquement pour la RC1 car à partir de la RC2 il y a eu un nettoyage d'une API (Interface de programmation) du noyau afin de la rendre plus propre et plus logique ce qui a provoqué la modification supplémentaire d'un grand nombre de pilotes (plus de 1100 fichiers nettoyés).

On voit donc que les développeurs Linux restent fermes dans leurs convictions : pas question pour l'instant d'ouvrir une branche 2.7 car le système incrémental actuel fonctionne bien. Pas question, non plus, de faire des compromis sur la propreté des API internes du noyau. Si les mainteneurs de pilote externes ne veulent pas intégrer le noyau, ils devront adapter leur code eux-mêmes.

NdM : On appréciera (ou pas ;-) ) le ton et l'humour inimitable de Linus lors de l'annonce : It's one of those rare "perfect" kernels. So if it doesn't happen to compile with your config (or it does compile, but then does unspeakable acts of perversion with your pet dachshund), you can rest easy knowing that it's all your own d*mn fault, and you should just fix your evil ways.

> Lire la dépêche (115 commentaires, moyenne: 3,4).  

Vous avez demandé le commentaire #780454.

Et pour les serveur Dell...

Posté par Mr F (page perso, ) le 30/11/2006 à 11:54. (lien). Évalué à 5.

On notera l'inclusion du patch de Matt Domsch permettant de réinverser l'ordre des interfaces réseaux des nouveaux serveurs de Dell (série 9) afin qu'elles soient enfin dans le bon sens (eth0 correspondant au label 1 et eth1 au label 2).

  • [^]Re: Et pour les serveur Dell...

    Posté par ashram4 () le 30/11/2006 à 12:41. (lien). Évalué à 4.

    ifname, ifrename ça ne permet pas de réglé ton problème ?

    • [^]Re: Et pour les serveur Dell...

      Posté par symoon (page perso, ) le 30/11/2006 à 14:09. (lien). Évalué à 3.

      ou peut-être plus moderne, udev ?

      • [^]Re: Et pour les serveur Dell...

        Posté par ashram4 () le 30/11/2006 à 14:25. (lien). Évalué à 2.

        il faut bien lui spécifier quelque part quelle carte sur quelle interface? udev c'est juste un système de gestion "dynamique" du repertoire /dev

        En plus les interfaces réseaux n'apparaise pas dans le répertoire /dev.

        le passage d'un noyau 2.4.?? à un 2.6.17 udev n'a rien changé pour mon problème de chargement carte/interface.

        • [^]Re: Et pour les serveur Dell...

          Posté par ookaze () le 30/11/2006 à 14:56. (lien). Évalué à 5.

          Que veux-tu dire ?
          Je change l'attribution de nom de mes interfaces avec Udev, et il décide en fonction de la MAC address (sensible à la casse depuis peu) chez moi.
          Je ne vois pas où est le problème, tu peux même scripter la détermination des MAC address si tu veux, avant de les passer à udev.

          • [^]Re: Et pour les serveur Dell...

            Posté par ashram4 () le 30/11/2006 à 15:07. (lien). Évalué à 0.

            tu as un lien sous la main? remarque c'est pas urgent je viens d'apprendre qu'on m'expédie une semaine en Corée. Je vais privilégié mon sommeil plutôt que mon PC pour les 2 prochains jours.

            • [^]Re: Et pour les serveur Dell...

              Posté par ribwund () le 30/11/2006 à 18:23. (lien). Évalué à 3.

              http://www.reactivated.net/writing_udev_rules.html#example-n(...)

              sinon la plupart des distros font ce genre de truc par defaut (ils fixent le nom de l'interface a l'install)

              • [^]Re: Et pour les serveur Dell...

                Posté par ashram4 () le 30/11/2006 à 21:20. (lien). Évalué à 1.

                merci, ça fait peu de temps que j'utilise un kernel 2.6 ça excuse un peu mon ignorance sur le sujet.

                • [^]Re: Et pour les serveur Dell...

                  Posté par nodens (page perso, ) le 01/12/2006 à 07:07. (lien). Évalué à 2.

                  En même temps c'est pas toujours très bien documenté.

                  J'ai découvert complètement par hasard hier comment ça marchait sous debian en cherchant pourquoi j'avais eth0 et eth2 avec seulement 2 interfaces; en fait il s'est avéré que le nombre d'interfaces a changé entre l'install et la suite, donc tout s'explique (et un grep "eth[[:digit]]" m'a permis de trouver le script dans /etc/udev) ;)

                  --
                  Clément Hermann (nodens)
                  - "L'air pur ? c'est pas en RL, ça ? c'est pas hors charte ?"
                  Jean in L'Histoire des Pingouins, http://tnemeth.free.fr/fmbl/linuxsf/
                  GPG : pgp.mit.edu - 0xEBD1399D

                  [^]Re: Et pour les serveur Dell...

                  Posté par ookaze () le 01/12/2006 à 10:17. (lien). Évalué à 2.

                  Je dois avoir des lignes de ce genre dans mon /etc/udev/rules/10-local.rules :
                  KERNEL=="eth*", SYSFS{address}=="MAC_sensible_casse", NAME="nom_interface_max_8_lettres"

                  Je ne saisplus quel paquet oblige à limiter le nom de l'interface réseau à 8 caractères max.
                  Je lance udev très tôt dans la séquence de boot, donc pas de souci.
                  Sinon, si qqch monte une interface avant qu'udev modifie le nom, tu ne peux plus le changer et tu restes avec eth*, si ton driver est dans le noyau.

                  • [^]Re: Et pour les serveur Dell...

                    Posté par Michel Pastor () le 01/12/2006 à 14:47. (lien). Évalué à 3.

                    Tu peux même si le driver est en dur dans le noyau il suffit que l'interface soit "down" pour pouvoir changer son nom.

        [^]Re: Et pour les serveur Dell...

        Posté par Mr F (page perso, ) le 06/12/2006 à 13:04. (lien). Évalué à 1.

        Oui mais...

        1. Cela n'empêche pas le problème à l'installation
        2. Il faut le gérer manuellement ou via un script
        3. Il faut faire du cas par cas/de la détection de situation.
        4. Ce n'est pas plus mal, au final, de se passer d'une couche et que le kernel agisse comme il le devrait, affecter eth0 à la première interface...

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0883s (dont 0.0068 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.