Journal : Atheros veut être compatible avec Linux
Posté par Mildred (Jabber id, page perso, ) le 28 avril 2008
Bonsoir,
Athreos fabrique des cartes wifi, et était jusqu'a présent supporté par le projet Madwifi¹. Ce projet comportant de nombreuses parties libres, mais il restait un point noir : le HAL, un code objet fermé (bien qu'indépendant du kernel, c'était le même code pour BSD et Linux).
Un HAL libre avait été en projet, mais d'après ce que je sais, il n'était pas très développé. Dernièrement, le projet madwifi a complètement été abandonné pour donner (pour Linux au moins) le driver ath5k². On en avait d'ailleurs parlé ici même³ en septembre dernier lorsque le projet OpenBSD avait repris le code du driver, et changer la licence trop vite.
Le 16 avil dernier, Luis R. Rodriguez a posté sur la liste ath5k-devel un message⁴ que je cite:
Good news. I write to you to inform you that I have decided to join Atheros as a full time employee, as a Software Engineer, to help them with their goals and mission to get every device of Atheros supported upstream in the Linux kernel. I realize there are a lot of challenges ahead but I am well aware of the how the community works and the benefits of working with it and am confident we will find ways to strengthen the relationship between Atheros and the community. I also realize there are a lot of pending questions and perhaps even more now. Please rest assured we are doing what we can to work together as soon as possible.
Si on traduit, cela donne:
Bonne nouvelles. Je vous écrit pour vous informer que j'ai décidé de me faire employer chez Atheros à plein temps comme ingénieur logiciel pour les aider dans leur mission consistant a ce que tous leurs produits soient supportés dans le kernel linux vanilla. Je me rends compte qu'il y a beaucoup de défis qui m'attendent, mais je suis bien au courant de comment la communauté fonctionne et des bienfaits à travailler ensemble, et j'ai confiance que nous trouverons un moyen de consolider la relation entre Atheros at la communauté. je me rend aussi compte qu'il y a beaucoup de questions attendant une réponse, et peut être encore plus à présent. Et restez assuré que nous faisons tout ce qui est possible pour pouvoir travailler ensemble aussi tôt que possible.
Ce qui est intéressant de noter, c'est que Atheros s'inquiète a ce que son métériel soit supporté dans le kernel vanilla. Donc cela eut dire que bientôt, on aura peut être plein de chipset atheros bien supportés dans le kernel sans avoir a rien faire.
On peut penser que cela est du entre autre a l'émergence de périphériques ultraportables comme le eeePc qui sont livrés avec Linux par défaut.
Il reste a espérer que les développeurs OpenBSD auront l'opportunité d'utiliser le code sans trop de problèmes. Soit parce qu'il sera bien documenté, soit parce que la licence leur permettra de le reprendre intégralement.
Sinon, je suis cela d'assez loin, donc je ne peux pas trop vous en dire plus. je ne peux pas non plus vous dire qui est Luis R. Rodriguez, si ce n'est u'il travaille depuis le début sur ath5k
Et merci d'excuser les éventuelles erreurs, il se fait tard :)
Mildred
¹ http://madwifi.org
² http://madwifi.org/wiki/About/ath5k
³ http://linuxfr.org/~IsNotGood/25195.html et http://linuxfr.org/~nicOnicO/25285.html
⁴ https://lists.ath5k.org/pipermail/ath5k-devel/2008-April/000(...)
Athreos fabrique des cartes wifi, et était jusqu'a présent supporté par le projet Madwifi¹. Ce projet comportant de nombreuses parties libres, mais il restait un point noir : le HAL, un code objet fermé (bien qu'indépendant du kernel, c'était le même code pour BSD et Linux).
Un HAL libre avait été en projet, mais d'après ce que je sais, il n'était pas très développé. Dernièrement, le projet madwifi a complètement été abandonné pour donner (pour Linux au moins) le driver ath5k². On en avait d'ailleurs parlé ici même³ en septembre dernier lorsque le projet OpenBSD avait repris le code du driver, et changer la licence trop vite.
Le 16 avil dernier, Luis R. Rodriguez a posté sur la liste ath5k-devel un message⁴ que je cite:
Good news. I write to you to inform you that I have decided to join Atheros as a full time employee, as a Software Engineer, to help them with their goals and mission to get every device of Atheros supported upstream in the Linux kernel. I realize there are a lot of challenges ahead but I am well aware of the how the community works and the benefits of working with it and am confident we will find ways to strengthen the relationship between Atheros and the community. I also realize there are a lot of pending questions and perhaps even more now. Please rest assured we are doing what we can to work together as soon as possible.
Si on traduit, cela donne:
Bonne nouvelles. Je vous écrit pour vous informer que j'ai décidé de me faire employer chez Atheros à plein temps comme ingénieur logiciel pour les aider dans leur mission consistant a ce que tous leurs produits soient supportés dans le kernel linux vanilla. Je me rends compte qu'il y a beaucoup de défis qui m'attendent, mais je suis bien au courant de comment la communauté fonctionne et des bienfaits à travailler ensemble, et j'ai confiance que nous trouverons un moyen de consolider la relation entre Atheros at la communauté. je me rend aussi compte qu'il y a beaucoup de questions attendant une réponse, et peut être encore plus à présent. Et restez assuré que nous faisons tout ce qui est possible pour pouvoir travailler ensemble aussi tôt que possible.
Ce qui est intéressant de noter, c'est que Atheros s'inquiète a ce que son métériel soit supporté dans le kernel vanilla. Donc cela eut dire que bientôt, on aura peut être plein de chipset atheros bien supportés dans le kernel sans avoir a rien faire.
On peut penser que cela est du entre autre a l'émergence de périphériques ultraportables comme le eeePc qui sont livrés avec Linux par défaut.
Il reste a espérer que les développeurs OpenBSD auront l'opportunité d'utiliser le code sans trop de problèmes. Soit parce qu'il sera bien documenté, soit parce que la licence leur permettra de le reprendre intégralement.
Sinon, je suis cela d'assez loin, donc je ne peux pas trop vous en dire plus. je ne peux pas non plus vous dire qui est Luis R. Rodriguez, si ce n'est u'il travaille depuis le début sur ath5k
Et merci d'excuser les éventuelles erreurs, il se fait tard :)
Mildred
¹ http://madwifi.org
² http://madwifi.org/wiki/About/ath5k
³ http://linuxfr.org/~IsNotGood/25195.html et http://linuxfr.org/~nicOnicO/25285.html
⁴ https://lists.ath5k.org/pipermail/ath5k-devel/2008-April/000(...)
> Lire le journal (48 commentaires, moyenne: 3,5).
Vous avez demandé le commentaire #926233.
Run by 
Cette page a été générée par Templeet en 0.0753s (dont 0.0072 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Une précision pour un mal comprenant
Excuse moi, mais ces histoires de wifi ne sont pas toujours simples à comprendre pour nous autres, personnes à compréhension réduite.
Est ce que ça veut dire 100% libre? Comme dans "pas de firmware"? Ou ça ne concerne que le pilote, qui deviendrait libre mais il resterait une partie firmware opaque?
[^]Re: Une précision pour un mal comprenant
D'après http://linuxwireless.org/en/users/Drivers/ath5k#features :
"This driver requires no firmware or binary-only HAL!"
ie " Ce pilote ne requiert aucun micrologiciel, ou couche d'abstraction matérielle uniquement binaire ! " ...
... bon, après, je dois avouer que, bien que Debianeux, je ne comprends pas trop le fouin autour des firmwares non libres, du moment qu'ils sont librement redistribuables (ce qu'ils sont déjà loin de toujours être, certes)...
Je vois un peu ça du même oeil que du matériel non libre, qu'on utilise avec du logiciel libre, et qui ne dérange pas tant de monde que ça... certes, je préfèrerais avoir des firmwares libres, qui tourneraient sur du matériel libre... mais mettre ça au même rang que les blobs en plein kernel ou userland, je trouve qu'il y a de l'abus, et que ça sème plus la confusion qu'autre chose...
[^]Re: Une précision pour un mal comprenant
Merci pour la précision.
... bon, après, je dois avouer que, bien que Debianeux, je ne comprends pas trop le fouin autour des firmwares non libres, du moment qu'ils sont librement redistribuables (ce qu'ils sont déjà loin de toujours être, certes)...
Ce n'est pas pour relancer le débat que j'ai demandé, mais pour être certain.
Au sujet des raisons qui motivent de demander des firmware libres, j'en vois plusieurs. Moins de confusion possible en est une, donc je ne mettrai de toutes façons pas "ça au même rang que les blobs en plein kernel ou userland".
Mais là on était bien dans le cas blob en userland avec le HAL binaire, non?
[^]Re: Une précision pour un mal comprenant
Mais là on était bien dans le cas blob en userland avec le HAL binaire, non?
Pour ce qui est du HAL binaire qui tourne avec madwifi, oui, complètement.
Et c'est une très bonne chose qu'on se dirige vers un futur où on en sera débarrassés... d'autant plus s'ils prévoient d'implémenter les "Virtual Access Points" (gérer plusieurs points d'accès complètement distincts, notamment sur le mode de chiffrement) de l'ancien driver, que je trouve, je le confesse, bougrement sexy... chose sur laquelle je peine, à mon grand dam, à trouver des précisions...
... et d'autant plus si on n'aura même pas à se soucier d'un firmware...
Par contre, la confusion que je vois surtout avec la chasse aux firmwares non libres, elle me semble issue de cette chasse même... à la base, on en vient essentiellement à utiliser des firmwares pour ne pas avoir à implémenter du matériel trop spécialisé, qu'il serait plus difficile de débuguer et de concevoir...
... mais le firmware reste pour moi du domaine du matériel... avoir un mauvais firmware revient à avoir un mauvais matériel, en ce qui me concerne.... et avoir un firmware non libre, à avoir du matériel non libre.
[^]Re: Une précision pour un mal comprenant
FYI, le support des VAP ont été commité dans FreeBSD le 20 Avril. Ça faisait bien 3 ans qu'ils nous en parlaient, ils l'ont fait (et pas que pour ath, le support est bien évidemment à 90% dans net80211).
[^]Re: Une précision pour un mal comprenant
... mais le firmware reste pour moi du domaine du matériel... et avoir un firmware non libre, à avoir du matériel non libre.
Entièrement d'accord.
Par contre, la confusion que je vois surtout avec la chasse aux firmwares non libres, elle me semble issue de cette chasse même...
Oui, elle vient du fait que ce qui précède n'est pas dit clairement, d'une part. Donc on fait comme si le problème des firmware était un problème de logiciels libres, alors que c'est un problème de matériel libre.
Mais de l'autre coté, à accepter et à s'habituer à avoir des firmware pas libre, on laisse le champ libre aux fabricants pour mettre dans celui ci des fonctions qui devraient être dans le pilote. (La situation du wifi est assez particulière pour montrer qu'il y a un problème particulier, et du coup, cette news est assez importante, je trouve.) D'où un autre type de confusion.
Ca dérive même ensuite jusqu'à des appareils comme la freebox et sa notion de "firmware". Et là on est bien dans le domaine des logiciels pas du matériel mais la confusion est possible parce que le terme est le même.
... et d'autant plus si on n'aura même pas à se soucier d'un firmware...
Tout à fait, et un autre avantage que je vois est au niveau de l'intégration dans les distributions. C'est juste pratique, moins stratégique, mais c'est important.
[^]Re: Une précision pour un mal comprenant
Pour moi avoir un firmaware non libre est équivalent à avoir un OS non libre. Après tout l'OS est au PC ce que le frimware est aux autres appareils électroniques programmable. Donc l'intérêt d'une généralisation des firmware libre me paraît évident : on ne pourrait plus avoir de compagnies qui construise des gammes virtuelles de produits par simple bradage logiciel par exemple. On pourrait (théoriquement) avoir un meilleur contrôle de ce que fait son materiel.
Pour être un peu plus concret on peut prendre des exemples issues du domaine de la photographie numérique : les appareils photos modernes sont de petits ordinateurs. Ils font par défaut tout un tas de traitement sur leurs entrées pour produire in fine des fichiers standards comme des jpegs. Mais certains utilisateurs préfèreaient pouvoir faire d'autres traitements sur les données que ceux proposés par le constructeur : avec un firmware libre des projets de firmware alternatifs seraient beaucoup moins difficile à développer et les résultats seraient bien plus probant que ce qui se fait actuellement. Autre exemple : les appareils photos numériques à objectifs échangeables olympus et panasonic sont sensés utiliser un standard de monture et de communication ouvert appelé four-thirds. Pourtant les communications se font très mal entre les appareils des deux marques. C'est assurément liés au fait que les deux tiennent à garder fermer et secrets leurs algorithmes et firmwares. Enfin, il arrive que les firmware propriétaire soit buggés. C'est le cas par exemple de ceux des appareils olympus et certains utilisateurs en essayant de faire des mises à jour de ces programmes se sont retrouvés avec du materiel inutilisable (reset impossible) à cause des logiciels alors qu'il n'y avait aucun dommage materiel. Je ne doute pas qu'avec des codes ouverts les programmeurs auraient pu réagir bien plus promptement à ce genre de problèmes !
Conclusion : il me semble que ce serait vraiment super d'avoir des firmware ouverts. Cela améliorerait surement les performances de nombreux produits et leurs capacités à satisfaire leurs utilisateurs. Mais surtout, à une époque ou les appareils électroniques assurent de plus en plus de fonctions et pourraient facilement se transformer en serviteurs de quelques bigbrothers privés, cela permetrait de redonner un peu de confiance à des consommateurs qui retrouveraient alors leur statut de citoyens à part entière...
PMA
[^]Re: Une précision pour un mal comprenant
> Pour moi avoir un firmaware non libre est équivalent à avoir un OS non libre
Je ne suis pas d'accord. Premièrement, un firmware tourne sur le périphérique directement et non pas sur la CPU, deuxièment, le firmware est censé remplacer la logique câblée pour des raisons de coûts. Le firmware peut-être considérée comme faisant partie du matériel. Normalement, le firmware ne doit pas sortir du périphérique mais pour des raisons de "flexibilité", on utilise de la mémoire volatile pour stocker celui-ci ce qui implique le pilote doit le recharger à chaque redémarrage. Demander le firmware pourrait être assimilé à demander les schémas électronique ou le source HDL de ton matos.
Le pilote ou la HAL, elle tourne sur le même CPU que le noyau, tourne dans le même processus. La problématique n'est donc pas la même.
Là, où je te rejoins est que la prochaine étape du logiciel libre sera de libérer les firmwares notamment le BIOS/EFI etc ...
[^]Re: Une précision pour un mal comprenant
Pour le Basic_Input_Output_System cela a l'air de bien avancer avec le projet linuxbios renommé en http://www.coreboot.org : il y a quelques cartes mères qui fonctionnent tout de même http://www.coreboot.org/Supported_Motherboards
À la base, le firmware - traduit par Micrologiciel - cela reste du logiciel, exécuté sur un CPU ou assimilé, même si c'est celui du périphérique et non de l'unité centrale. La question de sa licence se pose dès lors qu'il est distribué.
Les constructeurs nous ont habitués jusqu'à maintenant à des licences plus folkloriques les unes que les autres (propriétaire bien sûr... voire non distribuable dans la plupart des cas) ; quitte à demander une licence distribuable (comme une Licence_BSD 2-clauses), autant pousser jusqu'à avoir le code source ET les spécifications : cela permettra la correction de bugs effectivement, améliorera ipso-facto l'interopérabilité particulièrement importante dans le domaine des périphériques et permettra de progresser vers du tout libre.
Cela bénéficie à l'utilisateur final mais aussi aux intermédiaires : bien souvent le constructeur ne fait qu'assembler des composants d'autres constructeurs, mais au final c'est bien lui qui doit s'assurer qu'il y a une intégration et une interopérabilité correcte, dans ces cas-là disposer du firmware en libre peut simplifier la situation (pourquoi embarquer un correctif dans le pilote lorsqu'il pourrait corriger le firmware ? et inversement).
À ce titre, les personnes de OpenBSD font un travail efficace pour les pilotes, à coup de rétro-ingénierie coûteuse en temps, ce qui bénéficie tant au kernel *BSD qu'à Linux. Il y a aussi le projet de Greg Kroah Hartman dont le projet [http://www.linuxdriverproject.org/twiki/bin/view] a recensé 300 développeurs prêts à travailler sur des pilotes libres si les spécifications leur sont fournies
http://www.kroah.com/log/linux/linux_driver_project_status-2(...)
[^]Re: Une précision pour un mal comprenant
> un firmware tourne sur le périphérique directement
Exactement, le firmware est l'OS du périphérique en quelque sorte.
> Le firmware peut-être considérée comme faisant partie du matériel.
Il y en a qui ralent quand un fabriquant de PC dit que l'OS fais partie du matériel.
:-D !!!NOUVEAU!!!
[^]Re: Une précision pour un mal comprenant
> Exactement, le firmware est l'OS du périphérique en quelque sorte.
Tout dépends ce que tu appelles un firmware, si tu me parles du firmware de ton baladeur numérique, c'est effectivement un OS complet mais ce n'est pas le cas du firmware de ton graveur DVD.
Un point distinctif est que contrairement au second, le premier ne peut pas être remplacé par de la logique câblée.
> il y en a qui ralent quand un fabriquant de PC dit que l'OS fais partie du matériel.
Je doute qu'on puisse remplace un OS par de la logique câblée.
[^]Re: Une précision pour un mal comprenant
bien sûr que si on peut. La logique câblée étant Turing complet, rien ne s'y oppose si ce n'est peut-être le coût.
[^]Re: Une précision pour un mal comprenant
J'aimerais bien voir un OS complet en logique câblé.
Sur un plan théorique, c'est possible mais en pratique c'est autre chose, le coût financier n'est pas le seul obstacle.
à côté, réécrire Linux en brainfuck c'est du pipi de chat.
[^]Re: Une précision pour un mal comprenant
l'ENIAC ? :D (en plus ça fait longtemps qu'il existe)
[^]Re: Une précision pour un mal comprenant
L'ENIAC c'est une grosse calculette, pas un OS. :]
[^]Re: Une précision pour un mal comprenant
Et est-ce possible en pratique de refaire le firmware d'une carte wifi, voir d'un lecteur optique (avec tout les drm) en logique cablée ?
:-D !!!NOUVEAU!!!
[^]Re: Une précision pour un mal comprenant
Tout ce qui est programmable est faisable en logique cablée.
Après tout n'est que rapport prix / complexité / performance / ce que tu veux.
En général on voit des graphiques qui montre que plus la complexité augmente plus la logique cablée est chère.
[^]Re: Une précision pour un mal comprenant
Oui, donc la supposée distinction entre OS et firmware « qui fait partie du matériel » donnée par GeneralZod ne tient pas la route :-)
Probablement car il n'y a justement pas de distinction.
:-D !!!NOUVEAU!!!
[^]Re: Une précision pour un mal comprenant
Essentiellement, non...
... mais j'achète un ordinateur pour y mettre ce que je veux, comme par exemple un OS libre (ou pas... enfin, ça fait longtemps, que "ou pas", sur mes PC et assimilés, modulo ce que les gens peuvent trimballer dans leurs sacs quand ils viennent à me rendre visite)... j'achète une carte wifi pour établir une connexion sans-fil (voire en surveiller, tout au plus)...
Les versatilités respectives des deux catégories d'artefact ne sont quand même pas identiques, pour le commun des mortels...
... en outre, on trouve beaucoup de choses qui demandent d'y injecter un firmware, pour éviter la lourdeur de la logique câblée... mais si les firmwares libres devaient s'imposer, il ne faut pas rêver : les constructeurs reviendraient à des limitations en hard pour ce qui est de différencier les capacités de gammes de matériels qui ne diffèrent aujourd'hui que par le firmware, et pas physiquement... pour ce qui est du matériel destiné à des marchés de niches, vendu à une différence de prix pouvant aisément flirter ou cumuler l'ordre de grandeur, c'est d'ailleurs le cas, alors que le matériel, à une ou deux résistances prêt, est identique aux gammes pour les grouillots dont la plupart, moi le premier, sont (je pense notamment aux GPU "pro")...
Pour ce qui est du wifi d'ailleurs, régulations de ce qu'on peut faire sur les ondes radios obligent, il y a fort à parier qu'on doive se coltiner soit des limitations physiques du hard, soit des limitations codées dans le firmware... si l'on se débarasse des deuxièmes, il y a légalement peu de doutes quant à ce qu'on doive subir les premières... et face à un noyau qui implémente ces régulations légales dans un blob (comme les cartes Intel post IPW2xxx, avant la migration des régulations dans le firmware), personnellement, ça me semble être un moindre mal.
Maintenant, loin de moi l'idée de ne pas souhaiter la venue de matériel libre... pour utiliser avec mes OS libres... mais ce sont pour moi deux luttes distinctes, et il ne me paraît pas absurde que la première ne soit qu'une suite, sans corrélation absolue, à la deuxième... par contre, les confondre me paraît un peu trop intégriste (sans connotation fondamentalement négative, pour l'intégrisme, sinon, je n'aurais pas ajouté le "trop" : je ne vois conceptuellement rien de mal à être intègre... juste qu'à l'être trop, on en vient à être, probablement trop également, idéaliste... voire rêveur ; et on peut s'y perdre).