Sortie du noyau 2.6.14

Posté par  . Modéré par Nÿco.
Étiquettes :
0
28
oct.
2005
Noyau
La version 2.6.14 du noyau vient de sortir

Au menu :
  • L'intégration de FUSE, permettant de disposer de systèmes de fichiers implémentés en espace utilisateur;
  • L'intégration de V9FS, un pilote pour le système de fichiers distribué de Plan9;
  • L'intégration de RelayFS, un pseudo-système de fichiers permettant le transfert rapide de données entre le noyau et l'espace utilisateur;
  • L'intégration du support pour DCCP, un nouveau protocole réseau, situé au même niveau qu'UDP et TCP. Il est orienté datagrammes, comme UDP, mais gère la congestion, comme TCP. Un document de l'IETF apporte de nombreuses précisions sur le sujet;
  • Un meilleur mapping des claviers USB pour Apple PowerBook;
  • Beaucoup de modifications d'usbnet qui vont ravir tous les utilisateurs de PocketPC. Maintenant, "Linux peux discuter avec divers matériel basé sur WinCE";
  • Une correction permettant d'éviter les crashs sur les systèmes NFS à forte charge (meilleur gestion des inodes);
  • On peut maintenant accéder à des Cartes CF (en PCMCIA sur ARM) lors du boot;
  • Une meilleure gestion des cartes son en USB;
  • Des mises à jour sur l'ACPI
  • Ajout du pilote HostAP et du pilote ipw2100 et ipw2200;
  • Un nettoyage du code;

On peut aussi noter la création d'un flux RSS pour suivre le développement du noyau. Le noyau 2.6.14 est le premier à avoir suivi le nouveau modèle de développement mis en place par Linus à la sortie du 2.6.13. Pour rappel, suite à la sortie d'une version du noyau, des ajouts de fonctionnalités et modifications importantes ne seront acceptés que pendant deux semaines. Au delà de ce délai, et jusqu'à la sortie de la prochaine version, le travail des développeurs sera consacré à la correction de bugs.

Aller plus loin

  • # ieee80211 !

    Posté par  (site web personnel) . Évalué à 7.

    Enfin l'intégration du stack ieee80211 :-)

    Enfin un premier pas pour l'intégration de rt2x00 (http://rt2x00.serialmonkey.com) !

  • # re

    Posté par  (site web personnel) . Évalué à 0.

    J'ai toujours aimé la feature :
    Un nettoyage du code;

    Ca veut tout et rien dire ...

    • [^] # Re: re

      Posté par  . Évalué à 10.

      J'espère que ça veut pas dire qu'ils ont mis de l'ajax dans le noyau...

      • [^] # Re: re

        Posté par  . Évalué à -3.

        erf, ils auraient ajouté du javascript dans le noyau ? au secours :P

  • # petite erreur

    Posté par  . Évalué à 9.

    Un meilleur mapping des claviers USB pour Apple PowerBook;

    Non , c'est un meilleur support du touchpads des powerbooks sortis après février 2005 .

    • [^] # Re: petite erreur

      Posté par  . Évalué à 5.

      Une meilleure gestion des cartes son en USB

      Ca veut dire qu'il n'y aura plus le probleme de snd-usb-audio ?
      Donc, que le micro de la webcam fonctionnera même avec le pilote de la carte son?

      • [^] # Re: petite erreur

        Posté par  . Évalué à 7.

        Un probleme courant est qu'avec certains chipsets de carte mère (Nforce2, entre autres), le micro intégré de la webcam peut être détectée comme carte son principale, ce qui a pour effet, logiquement, de faire planter le moteur de son Alsa.
        Ceci est du au fait que le driver snd_usb_audio se charge avant le driver son du chipset, et se resoud en changeant simplement l'ordre de chargement des modules.

        Si c'est ton probleme, ce n'est pas un probleme dans le noyau je doute que le nouveau ameliore les choses.

        • [^] # Re: petite erreur

          Posté par  . Évalué à 5.

          Ok, je croyais que c'etait lié.

          Merci pour tes explications claires et pedagogiques.

  • # Claviers Powerbooks

    Posté par  . Évalué à 5.

    À noter que le "meilleur mapping des claviers USB pour Apple PowerBook" fait surtout que le patch [0] pour activer la gestion de la touche Fn ne marche plus. Il faudra attendre d'avoir un X qui gère le nouveau systeme.

    Il existe un patch qui désactive le nouveau système et revient à l'ancien, et qui est sensé pouvoir faire fonctionner la touche Fn. Il sera sans doute bientôt disponible sur le site [0].

    Je finis de compiler, je teste, et je vous tiens au courant...


    (à noter aussi que sur les powerbooks 15" avec la radeon 9600, on obtient du DRI avec le module du 2.6.14 (à condition d'avoir un Xorg cvs ([1] pour debian sid) et d'avoir libgl1-mesa-dri (à compiler soi même sous debian))

    [0]: http://seehuhn.de/comp/powerbook/#fnkey-patch
    [1]: http://people.debian.org/~luther/xorg-x11-6.8.99.901.dfsg.1-(...)

    • [^] # Re: Claviers Powerbooks

      Posté par  (site web personnel) . Évalué à 2.

      Ben .. j'ai une radeon 9600 sur un Athlon64, et la seule chose à recompiler c'était les modules DRM. Tout le reste est venu par apt-get (kernel 2.6.13, Xorg 6.8.99, libgl1-mesa-dri), de sid ou d'experimental. Et ça fonctionne pas trop mal, ma foi.

    • [^] # Re: Claviers Powerbooks

      Posté par  . Évalué à 2.

      Es-ce que DRI a des chance de fonctionner aussi sur mon PowerBook 17" ?

      Il a une Radeon 9700, mais en faite c'est une Radeon 9600 M10 je sais pas quoi, j'ai de la peine avec ces M quelque chose. La seule chose précise que je sais (que je crois savoir en tout cas) c'est que c'est une "RV350".
      J'ai fais des recherches sur le site de dri, ils disent que le support du RV350 est expérimental et que le support pour la platforme ppc est encore un peu bugé.
      (rendu OpenGL à la mauvaise place sur l'écran ou quelque chose comme ça), comme je sais pas du tout ou ça en est j'ai pas trop envi de tout casser ma distrib en essayant d'installer tout ça si c'est pour avoir un résultat complettement instable.
      (il m'a déjà fallu un moment pour recompiler un linux 2.6.12 avec les bonnes options pour pouvoir faire fonctionner la mise en veille, le support du backlight, l'usb 2 et plein d'autre choses j'ai pas envi de tout recommancer)
      Reste que la carte son que j'ai pas réussi à faire fonctionner et l'accélération 3D (en plus de la carte réseau BCM4306, mais y'a plus d'éspoire)

      PS : voila, j'ai fini de raconter ma vie et celle de mon portable :-P (mille excuses si j'ai fais des fautes de français, j'ai toutes les peines du monde à ne pas en faire, j'ai déjà relu beaucoup de fois avant de poster)

      • [^] # Re: Claviers Powerbooks

        Posté par  (site web personnel) . Évalué à 3.

        (mille excuses si j'ai fais des fautes de français, j'ai toutes les peines du monde à ne pas en faire, j'ai déjà relu beaucoup de fois avant de poster)

        Franchement, pour quelqu'un qui dit qu'il fait des fautes, il n'a pas grand chose à redire ! Si tu n'avais pas dit que tu faisais des fautes, je ne les aurais même pas remarquées.

        Il y a des gens qui font plus de fautes, qui le savent, mais qui n'en n'ont rien à foutre et qui ne se relisent pas. Bravo pour ta démarche.

        Je n'ai juste vu que quelques fautes de frappe, mais rien de bien méchant :
        s/en faite/en fait/
        s/bugé/bugué/
        s/envi/envie/
        s/complettement/completement/
        s/autre choses/autres choses/
        s/éspoire/espoir/

        • [^] # Re: Claviers Powerbooks

          Posté par  . Évalué à 3.

          Corollaire de la loi de Murphy : il y a toujours des fautes dans un message sur l'orthographe.

          complètement (avé l'assent, con ;o)

          Il manque aussi le « y » et le trait d'union ou l'apostrophe¹ dans « il n'y a pas grand'chose à redire ! ».

          ¹ : il n'y a plus grand monde pour utiliser l'apostrophe pour marquer l'absence du e...

      • [^] # Re: Claviers Powerbooks

        Posté par  . Évalué à 2.

        Le driver DRI pour r300 supporte toutes les cartes RADEON de la 7500 à la X850 (je ne sais plus quoi) en AGP. Il subsiste encore quelques problèmes avec le PCI-E.

        Il marche bien pour la platforme PPC. Le site r300.sf.net n'est pas très à jour :) Donc tu peux tester ce driver, mais attention il est encore en développement et il a tendance à "freezer" la machine avec les screensavers.

      • [^] # Re: Claviers Powerbooks

        Posté par  . Évalué à 2.

        Je dirais que, oui, t'as tout interet à tenter. Celà dit, peut être qu'effectivement ca marchait déjà avec le 2.6.13, comme dit au dessus. Moi j'ai eu besoin de la combinaison 2.6.14 + xorg 6.9.0RC1 + compilation propre de libgl1-mesa-dri (vu qu'il est pas dispo en ppc/unstable actuellement).

        Sinon, heu, sur le 17 je sais pas, mais sur le 15:

        suspend to ram > ok
        backlight > ok
        usb2 > ok
        carte son > ok (snd_powermac)

        Je ne saurais trop te conseiller le noyau 2.6.14-rc5 dispo sur http://people.debian.org/~luther/2.6.14-rc5/ (et bientot le 2.6.14 dispo dans unstable), ou y'aura tout ce qu'il faudra... ou presque.

        Sinon, le patch fn-key pour 2.6.14 marche très bien, je sais pas quand il sera uploadé sur le site, mais en attendant il peut se trouver dans les archives de la liste debian-ppc:
        http://lists.debian.org/debian-powerpc/2005/10/msg00470.html

        (penser à virer les commentaires imbriqués du patch, gcc aime pas trop)

  • # Reiser4?

    Posté par  . Évalué à 2.

    Et reiser4 il sera intégré quand?

    Remarque en attendant y a toujours les patchs...

    • [^] # Re: Reiser4?

      Posté par  (site web personnel) . Évalué à 7.

      il n'est pas près d'être intégrer. Son système de plugin est vue comme une violation d'interface par les dev noyaux. En gros, il lui demande d'intégrer le bidule au niveau vfs.

      "La première sécurité est la liberté"

      • [^] # Re: Reiser4?

        Posté par  . Évalué à 5.

        Par les devs noyaux ou par les devs de XFS ? Parce que généralement à chaque fois que le sujet est abordé sur la lkml c'est eux qui sortent cet argument. R4 propose tout plein de trucs tout "ouuuh shiny!" et c'est vraiment dommage qu'on ne puisse pas en profiter en vanilla.

        • [^] # Re: Reiser4?

          Posté par  . Évalué à 5.

          Sauf que quand tu vois ce genre de message:

          http://lkml.org/lkml/2005/9/16/178

          et spécialement "Most of my customers remark that Namesys
          code is head and shoulders above the rest of the kernel code.",
          tu te dis que forcément il va y avoir des anicroches....

          • [^] # Re: Reiser4?

            Posté par  . Évalué à 4.

            En réponse à Christoph Hellwig, dev XFS, disant que le code de R4 est tout pourri. Je trouve d'ailleurs la réponse de Hans assez marrante, enfin bon quand ils auront fini de se mettre sur la gueule après toutes ces années on finira bien par avoir R4 en-dehors de -mm...quoique vu les 2 lascars ça risque de prendre du temps.

            • [^] # Re: Reiser4?

              Posté par  . Évalué à 4.

              Christoph Hellwig n'est pas dev XFS. Il est le mainteneur de VFS, et a donc contribué à XFS (comme à d'autre systèmes de fichiers), mais ce n'est pas un dévelopeur de XFS.

        • [^] # Re: Reiser4?

          Posté par  . Évalué à 10.

          Tu reprends les calomnies de Hans Reiser à l'égard des devs de Linux. Si tu lisait mieux la LKML, tu te rendrais compte que le seul vrai obstacle à l'intégration de Resier4, c'est Hans Reiser. cf.
          http://www.kerneltraffic.org/kernel-traffic/kt20051010_331.h(...)

          Les développeurs de XFS n'ont rien à voir dans l'histoire. Les commentaires sur Reiser4 viennent surtout du responsable du VFS (virtual file system layer) de Linux, C. Hellwig. Il a listé des tâches que l'équipe de Namesys doit accomplir. Andrew Morton a pris note de cette liste. Les employés de Hans Reiser se sont mis au travail. Mais Reiser lui même a passé son temps à se plaindre.

          Il avait fait la même chose pour Reiser3. Quand il avait enfin cessé de la ramener sans cesse pour calomnier les developeurs du noyau, ces employés avaient fait le boulot et Linus avait intégré le noyau. Hélas, il n'a pas appris de ces erreurs passées.

          Le problème est qu'il n'y a que très peu de dévelopeurs Linux compétents dans ce domaine, avec du temps libre, et motivés pour relire un code aussi gros que celui de Reiser4. À vrai dire, il y en a 2. Et à chaque fois qu'ils mettent le doigt sur un problème, ils se font insulter.

  • # Netfilter

    Posté par  . Évalué à 10.

    Du côté du filtrage de paquets[0], les nouveautés sont nombreuses.
    On peut citer l'intgégration de nfnetlink et la sortie de la bibliothèque associée libnfnetlink[1]. Les deux ensemble forment un système permettant de faire communiquer des application userspace avec le noyau.
    Utilisant libnfnetlink, les bibliothèques suivantes sont aussi sorties:

    - libnetfilter_log[2] qui fournit une interface de log des paquets, et est notamment utilisée par ulogd2 [3].
    - libnetfilter_queue[4] qui permet à une application de gérer les paquets mis en attente par le noyau et de choisir des actions sur leur destin (drop, reject, ...). Le firewall authentifiant nufw[5] est un bon exemple de ce type d'interaction.
    - libnetfilter_conntrack[6]: cette bibliothèque fournit une API pour gérer le suivi des connexions. La commande conntrack l'utilise et permet de manipuler la table de suivi des connexions.

    [0] http://netfilter.org/index.html
    [1] http://netfilter.org/projects/libnfnetlink/index.html
    [2] http://netfilter.org/projects/libnetfilter_log/index.html
    [3] http://svnweb.gnumonks.org/branches/ulog/ulogd2/
    [4] http://netfilter.org/projects/libnetfilter_queue/index.html
    [5] http://nufw.org
    [6] http://netfilter.org/projects/libnetfilter_conntrack/index.h(...)

    • [^] # Re: Netfilter

      Posté par  (site web personnel) . Évalué à 1.

      Qu'est ce que cela apporte par rapport au netfilter/iptables classique ? Est ce que j'ai l'impression qu'on veut déplacer netfilter au niveau user ?
      Pourrais tu détailler un peu ?

  • # SD card

    Posté par  . Évalué à 3.

    Et aussi le support des cartes SD (pratique pour les utilisateurs d'appareils photos).

    • [^] # Re: SD card

      Posté par  . Évalué à 1.

      malheureusement, seul le controlleur Winbond W83L51xD est supporté.
      mon portable contient un ricoh R5C822, qui ne marchera donc pas :(

    • [^] # Re: SD card

      Posté par  (site web personnel) . Évalué à 5.

      C'est quoi le "support des cartes sd" ?

      Pour ma part je lis sans problème les cartes SD avec un lecteur de cartes et en passant par le module usb-storage !

      • [^] # Re: SD card

        Posté par  . Évalué à -1.

        Comment fais-tu ? Tu as un lien ?

        Merci

        • [^] # Re: SD card

          Posté par  (site web personnel) . Évalué à 3.

          tous les lecteurs de carte externes fonctionnent. (presque tous..moi j'en ai jamais vu un ne pas fonctionner)
          Par contre... les modules internes... c un autre probleme... aucun ne fonctionnait... la il semblkerait qu'un soit pris en compte.

        • [^] # Re: SD card

          Posté par  . Évalué à -1.

          je branche et gnome-volume-manager fais tout ce qu'il faut. Il m'ouvre une appli pour tout importer.

      • [^] # Re: SD card

        Posté par  . Évalué à 6.

        C'est quoi le "support des cartes sd" ?

        C'est le support d'un contrôleur SD Card intégré à la machine, et non externe, accessible en USB par exemple comme ce que tu décris. En effet, certains laptops arrivent avec des lecteurs de cartes flash, c'est assi le cas de PDAs (Zaurus par exemple), et il faut bien un driver pour pouvoir les utiliser.

        En outre, mais on a tendance à l'oublier, une carte SD, ce n'est pas qu'un simple stockage de données. SD, ça veut dire Secure Digital, et le mot Secure n'est pas juste là pour faire joli :

        http://actes.sstic.org/SSTIC05/Rump_sessions/SSTIC05-rump-Ke(...)

  • # ipw2100

    Posté par  (site web personnel) . Évalué à 3.

    Le code est bien dans le noyau, mais pas moyen de l'activé via menuconfig.
    J'ai tenté de le mettre à la main dans le .config mais make me le vire.
    Bon, tant pis, j'en avais besoin, je vais faire avec un 2.6.13

    • [^] # Re: ipw2100

      Posté par  . Évalué à 2.

      Il doit te manquer une dépendance...

      Voici l'information qui t'intéresse tiré du README fourni sur http://ipw2100.sourceforge.net :


      MAKE SURE THAT THE FOLLOWING CAPABILITIES ARE ENABLED:

      ~~~~~~~~~~~~~~~~~~~~~~~~~~~
      #define CONFIG_NET_RADIO 1
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Failure to enable this will result in the Wireless Tools (iwconfig, iwlist,
      etc.) not functioning. In 2.6.x, this is enabled via menuconfig:

      Device Drivers ->
      Networking support ->
      Network device support ->
      Wireless LAN (non-hamradio) ->
      Wireless LAN drivers (non-hamradio) & WE


      ~~~~~~~~~~~~~~~~~~~~~~~~~~~
      #define CONFIG_FW_LOADER 1
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~
      ipw2100 loads firmware via the Linux firmware hotplug capability (see later
      section on firmware loading). In 2.6.x, this is enabled via menuconfig:

      Device Drivers ->
      Generic Driver Options ->
      Hotplug firmware loading support


      ~~~~~~~~~~~~~~~~~~~~~~~~~~~
      #define CONFIG_CRYPTO 1
      #define CONFIG_CRYPTO_ARC4(_MODULE) 1
      #define CONFIG_CRC32(_MODULE) 1
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~
      ipw2100 uses the WEP encryption and decryption algorithms provided
      by the Linux kernel. To use WEP you must enable the Crypto library support
      (CONFIG_CRYPTO) and the ARC4 cipher algorithm (CONFIG_CRYPTO_ARC4) via:

      Cryptographic options ->
      ARC4 cipher algorithm

      You also need to enable the CRC32 (CONFIG_CRC32) algorithm via:

      Library routines ->
      CRC32 functions


      ~~~~~~~~~~~~~~~~~~~~~~~~~~~
      #define CONFIG_CRYPTO_MICHAEL_MIC(_MODULE) 1
      #define CONFIG_CRYPTO_AES_586(_MODULE) 1
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~
      If you wish to enable (optional) WPA support, you also need to enable the
      following Crypto library modules (in addition to those required for WEP above):

      Cryptographic options ->
      Michael MIC keyed digest algorithm
      AES cipher algorithms (i586)


      Une restriction néanmoins : la version incluse dans le kernel 2.6.14 est un peu plus ancienne que celle-ci (c'est le même README qui le dit). Donc il peut y avoir d'autres subtilités. Dans ce cas, direction /usr/src/linux/Documentation/...

      Bonne compilation !

    • [^] # Re: ipw2100

      Posté par  (site web personnel) . Évalué à 4.

      Il te faut aussi

      CONFIG_IEEE80211=m

  • # FUSE ... qu'est ce que cela va apporter ?

    Posté par  (site web personnel) . Évalué à 6.

    Il semblerait que FUSE permette de monter des systèmes de fichiers en espace utilisateur ...

    Concrètement, va-t-on enfin pouvoir ?
    - monter un système de fichiers FTP/SSH/... ?
    - monter une archive tar(.gz|.bz2)? et travailler directement dedans ?
    - monter ce qu'on veut, par exemple un fichier de conf où chaque variable serait un fichier et sa valeur, le contenu du fichier ?
    - ...

    Si oui, ce serait vraimment bien ...

  • # l'ATAPI-SATA

    Posté par  (site web personnel) . Évalué à 1.

    Bonjour,
    Un autre "nouvelle fonctionnalité" : il est désormais la possible d'activer l'ATAPI pour les lecteur CD/DVD en SATA, fonctionnalité qu'il fallait auparavant aller modifier manuellement dans les sources du noyau... Ceci veut dire qu'elle a beaucoup avancée (95% des fonctions SATA-ATAPI).
    Je sais que cette fonctionnalité n'est pas une révolution, mais ça permettra au heureux détenteurs de laptop récent de profiter de leur lecteur CD ;)
    @ +

  • # pilotes ipw2x00

    Posté par  . Évalué à 3.

    Je suis assez decu qu'on intègre des pilotes comme ipw2x00. Etant donné le firmware ca aurait été un signe assez fort de les laisser en dehors.

    • [^] # Re: pilotes ipw2x00

      Posté par  . Évalué à 4.

      Et le fait que prism54, qui nécessite également le chargement d'un firmware propriétaire, soit intégré depuis longtemps maintenant ne te fait pas grincer des dents ?

      • [^] # Re: pilotes ipw2x00

        Posté par  . Évalué à 2.

        Bin moi ça me fait grincer des dents dans les deux cas.

        Le problème ne se résume pas en questions d'éthique/liberté/... mais aussi de qualité et de support: celà ajoute encore un composant dont les developpeurs n'ont pas le controle, ce qui commence à faire beaucoup pour les drivers ipw* et prism54 (les constructeurs respectifs n'ont jamais accepté de fournir aucune spec ou doc).

        Leur intégration ne devrait pas être une raison pour ne pas boycotter ces chipsets (heureusement en ce qui les concerne, et en particulier prism54, on a d'autres raisons).

        Par contre on peut faire une "echelle de pénibilité" des firmwares propriétaires selon que le constructeur autoriser ou non la libre redistribution du binaire (et avec ou sans signature d'accords).

        Puisqu'on parle de cohérence dans les partis pris, il me semble que le cas pwc/pwcx (http://linuxfr.org/2005/05/31/19026.html ) n'était pas si différent mais à conduit au rejet du wrapper gpl par Linus ...

        • [^] # Re: pilotes ipw2x00

          Posté par  . Évalué à 3.

          Rien à voir, le wrapper était destiné à faire tourner du code dans le processeur principal, et non pas à transmettre un firmware au périphérique.

        • [^] # Re: pilotes ipw2x00

          Posté par  . Évalué à 4.

          Leur intégration ne devrait pas être une raison pour ne pas boycotter ces chipsets (heureusement en ce qui les concerne, et en particulier prism54, on a d'autres raisons).

          Tu conseilles quoi ?
          Surtout pour faire du mode AP ?

          Au passage il y a un projet pour faire un firmware libre pour les prism : http://jbnote.free.fr/islsm/doku.php

      • [^] # Re: pilotes ipw2x00

        Posté par  . Évalué à 2.

        si biensur, pourquoi encore un de plus ?

    • [^] # Re: pilotes ipw2x00

      Posté par  (site web personnel) . Évalué à 2.

      Dans ce cas, tu peux aussi abandonner le support de 2/3 des cartes DVB parce que là je peux te dire qu'il y en a un paquet des firmwares non libres ...

      • [^] # Re: pilotes ipw2x00

        Posté par  . Évalué à 2.

        Et n'oublions pas tous les firmwares non libre qui sont stockés dans des flash/eeprom de nos PC.
        Je ne citerais que le plus connu : le bios...

        • [^] # Re: pilotes ipw2x00

          Posté par  . Évalué à 2.

          Non, ce n'est pas le même problème pour les périphériques qui intègrent déjà leur bios.
          Dans ce cas il n'y a pas de contrainte sur la redistribution de l'OS.
          Heu... cf. ma réponse à Nicolas qui dit la même chose ci-dessous (j'ai la flemme de le re-écrire ;)

    • [^] # Re: pilotes ipw2x00

      Posté par  (site web personnel) . Évalué à 4.

      Il va falloir faire du ménage alors, parcequ'il n'y a pas beaucoup de periphs qui n'ont pas de firmware proprio. Le bios bien sur, mais aussi les disques dur ont un firmware proprio, tout comme les lecteurs/graveur cd/dvdrom, les scanner, imprimantes, chips audio, jusqu'a ta souris optique.
      Si on devait supprimer tout les drivers dans linux qui passent par un firmware proprio, il ne resterait plus grand chose de linux.
      La seul difference ici (et qui se fait de plus en plus), c'est que le firmware doit être uploadé à la carte avant de pouvoir l'utiliser, contrairement aux autres, ou le firmware est en ROM/EEPROM.
      A la limite, ca à même des avantages: tu peux au moins uploader n'importe quel autre firmware facilement, sans flasher, et donc écrire peut être ton propre firmware (en te basant sur de reverse engenering par exemple, ou en ayant la chance de plus en plus rare d'avoir une doc).

      Il ne faut pas confondre firmware proprio et driver proprio. Si les deux seraient certaienement mieux s'ils etaient documenté et libre, le firmware à au moins l'avantage d'être indépendant de l'OS qui tourne sur ta machine, en plus de tourner généralement sur un autre CPU (celui du peripherique en question), ce n'est pas le cas driver qui est dépendant de l'OS, et tourne en plus sur le CPU de ta machine.

      • [^] # Re: pilotes ipw2x00

        Posté par  . Évalué à 6.

        Je suis d'accord avec le fait qu'on ne peut pas se passer de BIOS propriétaires distribué dans les périphériques, et que ce n'est pas gravissime.

        Mais le problème n'est pas le même pour un bios intégré au périphérique et un périphérique dont le bios doit être chargé par le kernel.

        Lorsque le firmware n'est pas distribué avec le matériel, il doit l'être avec l'OS, et à ce moment sa licence est une question importante.

        Selon les constructeurs (mais c'est bien le cas pour intel et les firmwares ipw), celà pose des problèmes de distribution ; nous sommes soumis au bon vouloir des constructeur de nous accorder le droit de redistribuer le firmware. Dans certains cas le driver ne peut pas être inclus dans les distributions "libres" (librement dérivables) ou celles pour lesquelles aucune autorité ne peut signer un accord de certification. Et le jour ou Intel trouve plus pratique de ne pas distribuer le firmware autrement qu'en bundle .exe avec le driver windows, tu peut changer de carte (ou passer à ndis, ou windows, mais bon ...).

        Et je le répète, dans les deux cas nommé ici (Connexant/prism et Intel) la redistribution pose problème, et les constructeurs refusent de collaborer à tout niveaux (y compris pour les specs).

        ca à même des avantages: tu peux au moins uploader n'importe quel autre firmware facilement, sans flasher, et donc écrire peut être ton propre firmware

        Ici il n'y a aucune différence avec un firmware qu'on peut flasher en EPROM. Si le constructeur te fournis un firmware (eg. vieux prismII/prism2.5), tu peut aussi le reverse engeneerer etc.

        Cette nouvelle tendance au firmware chargé dynamiquement par l'OS dans certains chipsets wifi est surtout motivée par un sens de l'économie de bouts de chandelle de la part des constructeurs, qui s'épargnent ainsi quelques kilos de rom...

        • [^] # Re: pilotes ipw2x00

          Posté par  . Évalué à 1.

          Dans certains cas le driver ne peut pas être inclus dans les distributions "libres" (librement dérivables) ou celles pour lesquelles aucune autorité ne peut signer un accord de certification.
          Le driver ne contient pas le firmware, le chargement se fait de maniere dynamique avec l'interface firmware du noyau.
          Apres si le firmware n'est pas libre, c'est a l'utilisateur de le mettre ou il faut, tout comme pour certains periphs il est necessaire de rebooter sous windows pour flasher une version qui marche sous linux.
          Pir certains drivers suporte des chips qui n'ont pas besoin de firmware et d'autre qui en ont besoin...

          Et le jour ou Intel trouve plus pratique de ne pas distribuer le firmware autrement qu'en bundle .exe avec le driver windows, tu peut changer de carte (ou passer à ndis, ou windows, mais bon ...).
          Tu as toujours l'ancien ?
          Sinon il y aura toujours moyen de faire des scripts qui l'extrait du exe (c'est ce qui est fait pour de nombreux firmware...)


          Cette nouvelle tendance au firmware chargé dynamiquement par l'OS dans certains chipsets wifi est surtout motivée par un sens de l'économie de bouts de chandelle de la part des constructeurs, qui s'épargnent ainsi quelques kilos de rom...
          Oui, de meme on retrouve de plus en plus de chips softmac (ie ou presque tout est fait dans le kernel, la carte se contant du minimun).

          D'un autre cote qu'est ce qui l'interesse la majeur partie des utilisateurs ?
          -Le prix,
          -une carte qui fait tout sur un hardware dedie (mais l'utilisateur a deja un proc dont il n'utilise pas la moitie des resources),
          -une carte qui contient sont firmware (l'utilisateur lamda ne regarde pas comment sont fait les drivers, du moment que ca marche il s'en fou...)
          [-une carte avec des specs et un driver libre]

          PS : dans le meme genre economie de chandelle, certaines cartes n'ont pas assez de ram pour contenir tout le firmware et celui-ci est swappé dans la RAM de la machine hote...

          • [^] # Re: pilotes ipw2x00

            Posté par  . Évalué à 7.

            Le driver ne contient pas le firmware

            Oui oops ma langue à fourchée ! je voulais dire bien sur dire : "Dans certains cas le firmware ne peut pas être inclus dans les distributions".

            Tu as toujours l'ancien ?

            Ou tu ne l'a jamais eu parceque tu vient d'acheter la carte. Et personne n'a le droit de te le refiler sans accord avec le constructeur ... dommage ;)

            Sinon il y aura toujours moyen de faire des scripts qui l'extrait du exe

            Oui, problable. Mais bon ... on sombre dans le très bricolo, très fragile, et fort peu intégré (c'est pas vraiment du fonctionnement out-of-the-box).

            D'un autre cote qu'est ce qui l'interesse la majeur partie des utilisateurs ?
            -Le prix,

            En l'occurence l'utilisateur trouvera vraissemblablement son chipset Intel intégré dans son portable centrino (ou autre), et je doute que les 1 ou 2 euros de la rom fassent la différence. Si l'utilisateur avait vraiment le choix et se préoccupait surtout du prix, il prendrait surement du ralink (avec firmware) et boycotterai, par ex, le prismgt/prism54 (sans firmware). Donc ça tomberai plutot bien ;) (par contre il raterait l'excellent atheros, qui est quand même très cher). Malheureusement l'utilisateur n'a pas le choix, et il se retrouvera souvent, par exemple, avec une carte graphique chère et au gpu surpuissant qui ne lui sert à rien (avec, à coté, un winmodem idiot, une carte wifi sans firmware, et bientot un chipset de drm tcpa ...).

            Je ne sait pas pour vous, mais je trouve que l'évolution / l'utilisabilité des technos 802.11a/b/g (sous Linux & *BSD en particulier) est de plus en plus byzantine. On avait quand même moins de conneries avec les bons vieux chipsets ethernet je trouve. Mais il faut dire que c'etait une techno qui avait murit dans le monde pro avant de toucher le grand public ...

          • [^] # Re: pilotes ipw2x00

            Posté par  . Évalué à -2.

            Le driver ne contient pas le firmware

            Oui oops ma langue à fourchée ! je voulais dire bien sur dire : "Dans certains cas le firmware ne peut pas être inclus dans les distributions".

            Tu as toujours l'ancien ?

            Ou tu ne l'a jamais eu parceque tu vient d'acheter la carte. Et personne n'a le droit de te le refiler sans accord avec le constructeur ... dommage ;)

            Sinon il y aura toujours moyen de faire des scripts qui l'extrait du exe

            Oui, problable. Mais bon ... on sombre dans le très bricolo, très fragile, et fort peu intégré (c'est pas vraiment du fonctionnement out-of-the-box).

            D'un autre cote qu'est ce qui l'interesse la majeur partie des utilisateurs ?
            -Le prix,

            En l'occurence l'utilisateur trouvera vraissemblablement son chipset Intel intégré dans son portable centrino (ou autre), et je doute que les 1 ou 2 euros de la rom fassent la différence. Si l'utilisateur avait vraiment le choix et se préoccupait surtout du prix, il prendrait surement du ralink (avec firmware) et boycotterai, par ex, le prismgt/prism54 (sans firmware). Donc ça tomberai plutot bien ;) (par contre il raterait l'excellent atheros, qui est quand même très cher). Malheureusement l'utilisateur n'a pas le choix, et il se retrouvera souvent, par exemple, avec une carte graphique chère et au gpu surpuissant qui ne lui sert à rien (avec, à coté, un winmodem idiot, une carte wifi sans firmware, et bientot un chipset de drm tcpa ...).

            Je ne sait pas pour vous, mais je trouve que l'évolution / l'utilisabilité des technos 802.11a/b/g (sous Linux

        • [^] # Re: pilotes ipw2x00

          Posté par  . Évalué à 2.

          Le problème des firmware chargés par le driver, je pense plutôt que c'est pour faciliter la maintenance. Mettre à jour le firmware se résume à une mise à jour du driver, alors que dans le cas d'un firmware dans une EEPROM, c'est diablement plus compliqué.

          De même pour le Softmac, on corrige plus facilement du code que du matériel. Ceci étant, la finalité c'est bien de réduire les coûts.

          • [^] # Re: pilotes ipw2x00

            Posté par  (site web personnel) . Évalué à 4.

            Effectivement pour la maintenance c'est sympatique.

            Simplement, il faudrait avoir une licence correcte (genre au pire 2-clause BSD qui n'oblige pas forcément à fournir le code) pour la distribution : en effet, l'utilisateur qui a besoin d'envoyer le firmware à son équipement de connexion au réseau (LAN ou Internet) il se retrouve un peu comme un con pour aller le récupérer sur internet ce foutu firmware qui ne peut pas être intégré dans les distributions libres à cause d'une licence abracadabrantesque...

            C'est tout de même l'utilisateur qui est le plus pénalisé dans cette affaire : une licence n'a jamais empêché les concurrents de décompiler / désassembler un firmware (ils utilisent en plus souvent les mêmes composants...). Autant ne pas le distribuer du tout dans ces conditions ! (ce qu'on pourrait penser de certains constructeurs vu la difficulté à retrouver le bon firmware pour le bon modèle, aucun changelog ni description n'étant fournis bien sûr...).

            Bien sûr un firmware GPL simplifie tout : si un concurrent veut l'utiliser, il devra fournir le code à son tour lors de la distribution => les utilisateurs bénéficient de plus de fonctionnalités (le firmware n'est pas redéveloppés 15 fois...), les constructeurs bénéficient des fonctionnalités supplémentaires voire les correctifs plus rapidement et leurs équipements en viennent à mieux se vendre (robustesse / fiabilité reconnue toussa)... en plus avec l'approbation et les encouragements de la communauté, que demande le peuple !

            • [^] # Re: pilotes ipw2x00

              Posté par  (site web personnel) . Évalué à 1.

              sans lancer du troll bcp de compagnie utilise du GPL, mais ont tellement peur des concurrents qu'elles ne liberent pas le code ou meme mentionne qu'elle utilise un system a base de linux/bsd ou autre.

              Je pense que ca doit etre de plus en plus vrai dans la micro embarqué .. personne veut donner ca recette de cuisine car coup de dev trop cher, concurrence trop féroce au final au lieu d'accélérer l'innovation ca ralenti parce que les constructeurs n'ont pas le temps d'amortir leur coup.
              Enfin c'est juste une pensée.

              puis y'en a d'autre on va pas citer broadcom .. qui font des chipset @~~@~{~@:~@$:%~£@:%£ buguéS .. avec des bidouilles dans le driver.

              Mes 3 sous.

              http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk

        • [^] # Re: pilotes ipw2x00

          Posté par  (site web personnel) . Évalué à 5.

          Et je le répète, dans les deux cas nommé ici (Connexant/prism et Intel) la redistribution pose problème, et les constructeurs refusent de collaborer à tout niveaux (y compris pour les specs).

          drivers/net/wireless/ipw2200.c
          Copyright(c) 2003 - 2004 Intel Corporation. All rights reserved.
          Contact Information:
          James P. Ketrenos <ipw2100-admin@linux.intel.com>
          Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497


          Je n'ai effectivement pas trouvé de specs, mais prétendre que des constructeurs qui sortent des drivers GPL refusent de collaborer à tous niveaux, c'est un peu abusé.

      • [^] # Re: pilotes ipw2x00

        Posté par  . Évalué à 4.

        Je suis d'accord avec le fait qu'on ne peut pas se passer de BIOS propriétaires distribué dans les périphériques, et que ce n'est pas gravissime.

        Mais le problème n'est pas le même pour un bios intégré au périphérique et un périphérique dont le bios doit être chargé par le kernel.

        Lorsque le firmware n'est pas distribué avec le matériel, il doit l'être avec l'OS, et à ce moment sa licence est une question importante.

        Selon les constructeurs (mais c'est bien le cas pour intel et les firmwares ipw), celà pose des problèmes de distribution ; nous sommes soumis au bon vouloir des constructeur de nous accorder le droit de redistribuer le firmware. Dans certains cas le driver ne peut pas être inclus dans les distributions "libres" (librement dérivables) ou celles pour lesquelles aucune autorité ne peut signer un accord de certification. Et le jour ou Intel trouve plus pratique de ne pas distribuer le firmware autrement qu'en bundle .exe avec le driver windows, tu peut changer de carte (ou passer à ndis, ou windows, mais bon ...).

        Et je le répète, dans les deux cas nommé ici (Connexant/prism et Intel) la redistribution pose problème, et les constructeurs refusent de collaborer à tout niveaux (y compris pour les specs).

        ca à même des avantages: tu peux au moins uploader n'importe quel autre firmware facilement, sans flasher, et donc écrire peut être ton propre firmware

        Ici il n'y a aucune différence avec un firmware qu'on peut flasher en EPROM. Si le constructeur te fournis un firmware (eg. vieux prismII/prism2.5), tu peut aussi le reverse engeneerer etc.

        Cette nouvelle tendance au firmware chargé dynamiquement par l'OS dans certains chipsets wifi est surtout motivée par un sens de l'économie de bouts de chandelle de la part des constructeurs, qui s'épargnent ainsi quelques kilos de rom...

        • [^] # Re: pilotes ipw2x00

          Posté par  (site web personnel) . Évalué à 1.

          Lorsque le firmware n'est pas distribué avec le matériel, il doit l'être avec l'OS, et à ce moment sa licence est une question importante.

          Oui, c'est vrai que ca pose toujours le problème de l'integration dans une distribution. Mais en ce qui concerne le choix de Linus (post initial), il aurait était idiot de le refuser.

          Ici il n'y a aucune différence avec un firmware qu'on peut flasher en EPROM. Si le constructeur te fournis un firmware (eg. vieux prismII/prism2.5), tu peut aussi le reverse engeneerer etc.

          Non, ce n'est pas aussi simple: flasher une EEPROM peut rendre le peripherique complétement inutilisable, mais surtout rendre le reflashage impossible. Ce n'est pas le cas ici, au pire, il suffit de reseter le periph, ou rebooter.

          Cette nouvelle tendance au firmware chargé dynamiquement par l'OS dans certains chipsets wifi est surtout motivée par un sens de l'économie de bouts de chandelle de la part des constructeurs, qui s'épargnent ainsi quelques kilos de rom...

          Il est evident que l'interet des constructeur n'est pas de permetre qu'on bidouille leur firmware ;) et avoir le firmware en ROM simplifirait les problèmes de license et d'integration pour les distributions.

          • [^] # Re: pilotes ipw2x00

            Posté par  (site web personnel) . Évalué à 6.

            Comme le cas des cartes Ralink RT2500/RT2400/RT2570 qui intégrent l'intégralité du firmware dans l'EEPROM.

            Le futur pilote en dev sera apparemment un des seul pilotes n'ayant aucun firmware a distribuer et sera intégré au kernel en intégralité :-)

            => http://rt2x00.serialmonkey.com

            Ces cartes sont peu cheres, se trouvent facilement (Asus, MSI,..), et les pilotes actuels ont été fournis par Ralink en GPL avec des doc des cartes.

            • [^] # Re: pilotes ipw2x00

              Posté par  . Évalué à 4.

              Le futur pilote en dev sera apparemment un des seul pilotes n'ayant aucun firmware a distribuer et sera intégré au kernel en intégralité :-)
              heu...
              les anciennes cartes wifi avaient aussi tout dans l'eeprom.
              C'est le cas de mon aironet qui au passage se presente comme une simple carte ethernet et fait tout le boulot de conversion 802.3<->802.11 en interne.


              Ces cartes sont peu cheres, se trouvent facilement (Asus, MSI,..), et les pilotes actuels ont été fournis par Ralink en GPL avec des doc des cartes.
              Et ils ont meme fournis des cartes aux developpeurs bsd pour qu'il puisse developper leur pilotes.

  • # Fuse & encfs

    Posté par  . Évalué à 4.

    Génial, je pourrais arrêter de compiler fuse en module et séparément pour des filesystem encryptés.

    Le gros avantage est que si un utilisateur monte son système encrypté, seul lui peut en lire le contenu, personne d'autre même pas root (sauf avec un su évidemment).

    Très bonne nouvelle :-D

    encfs http://encfs.sourceforge.net/

  • # Disparition de devfs et ramdisks

    Posté par  . Évalué à 5.

    avec le 2.6.13 déjà, les lignes de codes de devfs avaient été commentées ou effacées. Un des plus gros changements est que les ramdisks ne peuvent plus être générés par les outils initrd classiques et que les distributions doivent chercher des alternatives pour générer ces images (utile pour éviter l'inflation du noyau quand on veut pouvoir démarrer sur tout type de système, pour un noyau maison, il reste souvent plus simple de choisir ses propres modules/drivers noyau sans utiliser /initrd).

    Chez Debian, ca se joue pour le moment entre les outils initramfs (utilisés par Ubuntu) et les outils yaird, mais rien n'est vraiment décidé pour le moment, vu que ces deux outils sont assez jeunes.

    Qu'en est-il chez les autres ?

    http://www.xs4all.nl/~ekonijn/yaird/yaird.html
    http://people.ubuntu.com/~jbailey/bzrtree/initramfs-tools/ (celle là est assez fruste, je n'ai pas trouvé mieux encore)

  • # Et cooker...

    Posté par  . Évalué à -5.

    Et la cooker de Mandriva est toujours sur le 2.6.12, ça fait pas serieux, je prefère Ubuntu, avec le dernier kernel bien patché.


    PS: Humour inside

  • # kernel-headers

    Posté par  . Évalué à 1.

    Heu et pour compiler les modules nvidia on fait comment?

    Parceque module-assistant ne trouve pas le pakcage et moi non plus :)...

    C'est juste une question de temps avant qu'ils n'apparaissent dans l'archive Debian ou les kernel-headers ne sont pas inclus dans Sid?

    Sinon, si quelqu'un sait où je peux les télécharger...

    err747 qui se demande si il va devoir se passer de ses drivers... (pas une grosse perte mais quand même)

    • [^] # Re: kernel-headers

      Posté par  . Évalué à 4.

      Afin de préparer l'arrivée de noyaux autres que Linux dans Debian, c'est maintenant linux-headers* ainsi que linux-image* au lieu des kernel*.

      Dans ton cas, tu peux utiliser linux-headers-2.6.14 disponible dans Sid.

Suivre le flux des commentaires

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