Le support Wifi est globalement OK (certains chipsets ne sont pas supportés, mais ce sont généralement des chipsets relativements peu courants, et pour d'autres le support est à mon goût beaucoup plus carré que sous Linux), pas de suspend to disk/to ram ACPI, pas de bluetooth. Pour moi ce sont des détails donc je trouve que ça roule bien sur un portable.
Si tu veut tout savoir sur le support du matériel sur x86, regarde ici: http://www.openbsd.org/i386.html (et http://www.openbsd.org/macppc.html pour les macs).
Commentaire au sujet du journal: le driver Linux n'utlise pas exactement un « blob opaque qui tourne en espace noyau ». Mais ce driver Linux dépend d'un daemon close source et propriétaire qui tourne en root (et qui cause avec le driver, donc le noyau). Ça, c'était une grande innovation délirante d'Intel, qui avait beaucoup fait jaser, cf. http://kerneltrap.org/node/6270 .
Bref, ce qu'explique Damien Bergamini, c'est que son driver de 3000 lignes fonctionne sans ce daemon propriétaire, qui est nécéssaire au driver Linux (écrit par Intel).
De plus, pour être très précis, on ne peut pas vraiment dire que le driver OpenBSD, pour fonctionner, n'utilise « aucun binaire opaque »: il reste le firmware (binaire, closed source) de la carte à charger à l'intialisation. Mais il est vrai que le firmware ne tourne pas dans le noyau (ni même en userland), il est seulement chargé dans la carte wifi puis exécuté par celle-ci.
La performance de Damien est assez somptueuse, lorsqu'on sait qu'Intel ne lui a pas donné de doc, et qu'il a fait son driver en reverse engeneerant le driver Linux, en trouvant moyen de le réduire au 1/6em en nombre de lignes, de virer la dépendance au daemon root propriétaire, tout ceci en seulement 2 mois après qu'Intel ai publié le driver Linux.
Ce n'est pas le coup d'essai de Damien, il a aussi oeuvré pour les drivers OpenBSD des autres chipsets Wifi Intel, là aussi en reverse engeneerant le driver Linux et en trouvant moyen de le rendre beaucoup plus petit et lisible.
On peut aussi citer son admirable travail pour les chipsets Wifi Ralink (société qui, elle, donne les docs et des firmwares redistribuables): en quelques mois son driver marchait mieux que le driver Linux fournis par Ralink (par comparaison, le projet http://rt2x00.serialmonkey.com de réécriture de ce driver sous Linux patauge depuis presque deux ans sans résultat probant, ce qui montre que ce n'est pas facile).
Sur le lien kerneltrap que je donne ci-dessus, vous pourrez remarquer combien le developpeur kernel Linux Christoph Hellwig a vu juste (et Alan Cox a vu faux), lorsqu'il dit: « If intel doesn't do the right thing support for their hardware will have to wait until someone has reverse-engineered their daemon » !
[^] # Re: Petite question...
Posté par herodiade . En réponse au journal Driver wifi pour OpenBSD. Évalué à 10.
Si tu veut tout savoir sur le support du matériel sur x86, regarde ici:
http://www.openbsd.org/i386.html (et http://www.openbsd.org/macppc.html pour les macs).
Commentaire au sujet du journal: le driver Linux n'utlise pas exactement un « blob opaque qui tourne en espace noyau ». Mais ce driver Linux dépend d'un daemon close source et propriétaire qui tourne en root (et qui cause avec le driver, donc le noyau). Ça, c'était une grande innovation délirante d'Intel, qui avait beaucoup fait jaser, cf. http://kerneltrap.org/node/6270 .
Bref, ce qu'explique Damien Bergamini, c'est que son driver de 3000 lignes fonctionne sans ce daemon propriétaire, qui est nécéssaire au driver Linux (écrit par Intel).
De plus, pour être très précis, on ne peut pas vraiment dire que le driver OpenBSD, pour fonctionner, n'utilise « aucun binaire opaque »: il reste le firmware (binaire, closed source) de la carte à charger à l'intialisation. Mais il est vrai que le firmware ne tourne pas dans le noyau (ni même en userland), il est seulement chargé dans la carte wifi puis exécuté par celle-ci.
La performance de Damien est assez somptueuse, lorsqu'on sait qu'Intel ne lui a pas donné de doc, et qu'il a fait son driver en reverse engeneerant le driver Linux, en trouvant moyen de le réduire au 1/6em en nombre de lignes, de virer la dépendance au daemon root propriétaire, tout ceci en seulement 2 mois après qu'Intel ai publié le driver Linux.
Ce n'est pas le coup d'essai de Damien, il a aussi oeuvré pour les drivers OpenBSD des autres chipsets Wifi Intel, là aussi en reverse engeneerant le driver Linux et en trouvant moyen de le rendre beaucoup plus petit et lisible.
On peut aussi citer son admirable travail pour les chipsets Wifi Ralink (société qui, elle, donne les docs et des firmwares redistribuables): en quelques mois son driver marchait mieux que le driver Linux fournis par Ralink (par comparaison, le projet http://rt2x00.serialmonkey.com de réécriture de ce driver sous Linux patauge depuis presque deux ans sans résultat probant, ce qui montre que ce n'est pas facile).
Sur le lien kerneltrap que je donne ci-dessus, vous pourrez remarquer combien le developpeur kernel Linux Christoph Hellwig a vu juste (et Alan Cox a vu faux), lorsqu'il dit: « If intel doesn't do the right thing support for their hardware will have to wait until someone has reverse-engineered their daemon » !