11 points par GN⁺ 2026-02-24 | 3 commentaires | Partager sur WhatsApp
  • La puce Broadcom BCM4350 du MacBook Pro 2016 n’est pas prise en charge nativement par FreeBSD ; jusqu’ici, la solution courante consistait à contourner le problème avec wifibox via une VM Linux
  • L’auteur a d’abord tenté de porter sur FreeBSD le pilote Linux brcmfmac avec Claude Code, mais a échoué à cause de kernel panics et de problèmes de compatibilité avec LinuxKPI
  • Il a ensuite utilisé Pi coding agent pour analyser le fonctionnement de brcmfmac et faire rédiger par l’IA une spécification technique en 11 chapitres dédiée au BCM4350
  • Après avoir complété cette spécification par validation croisée avec plusieurs modèles d’IA (Opus, Codex, Gemini, etc.), il a pu générer entièrement automatiquement un nouveau pilote pour FreeBSD sur cette base
  • Le résultat est un module noyau prenant en charge le scan Wi‑Fi, les connexions 2,4/5 GHz et l’authentification WPA/WPA2, et le code a été publié sur GitHub

Contexte

  • Le MacBook Pro 2016 utilise une puce Wi‑Fi Broadcom BCM4350, mais FreeBSD ne dispose d’aucun pilote natif pour cette puce
    • Sur les forums FreeBSD, la méthode généralement recommandée consiste à utiliser le pilote brcmfmac via une VM Linux appelée wifibox
  • brcmfmac est le pilote Linux de Broadcom pour les puces FullMAC ; il délègue au firmware interne de la puce des tâches comme le traitement des trames 802.11 et le chiffrement WPA
  • Pour créer un module natif FreeBSD, il faut adapter une partie du code Linux à FreeBSD via une conversion de « glue code »

Acte 1 — Première tentative avec Claude Code

  • L’auteur a essayé d’utiliser Claude Code pour convertir le code de brcmfmac vers FreeBSD
    • Il lui a demandé de s’appuyer sur la couche de compatibilité LinuxKPI de FreeBSD, en suivant l’approche du pilote Intel iwlwifi
  • Le module compilait, mais ne fonctionnait pas sur le vrai matériel et provoquait des kernel panics
  • Claude a ajouté des blocs #ifdef __FreeBSD__ pour corriger le code, mais l’ensemble restait instable à cause de défauts de LinuxKPI
  • L’IA a averti que le projet risquait de devenir « complexe et désordonné », et au final il ne restait que du code non fonctionnel

Acte 2 — Approche fondée sur une spécification

  • L’auteur a ensuite utilisé Pi coding agent pour analyser l’architecture du pilote brcmfmac en se concentrant sur le BCM4350, puis lui a fait rédiger une spécification détaillée pour une implémentation clean room
  • L’IA a généré un document composé de 11 chapitres
    • Par exemple : 00-overview.md, 04-firmware-interface.md, 08-data-path.md
  • L’auteur s’est servi du modèle Codex pour vérifier et corriger les écarts entre la spécification et le code réel
  • Il a ensuite refait une vérification avec le modèle Opus pour confirmer que les corrections correspondaient bien au code
  • Après comparaison de plusieurs modèles, il indique que Gemini 3 Pro preview est celui qui a produit le plus d’erreurs (« hallucinations »)

Acte 3 — Construction d’un nouveau pilote FreeBSD

  • Sur la base de cette spécification, il a lancé un projet de réécriture d’un pilote FreeBSD pour le BCM4350
  • L’IA a documenté les décisions de conception : structure du projet, langage (usage ou non du C), dépendance à LinuxKPI, jalons, etc.
  • Le projet s’appuyait d’abord sur LinuxKPI, mais a ensuite basculé vers du code FreeBSD natif en raison de la complexité croissante
  • L’IA accédait à l’hôte de build et à la VM de test en SSH afin d’exécuter une boucle automatisée de build et de test
    • Il était configuré pour résumer et consigner la cause à chaque crash de la VM
  • Au terme de nombreuses itérations, un module noyau capable d’assurer le scan Wi‑Fi, les connexions 2,4 GHz / 5 GHz et l’authentification WPA/WPA2 a été finalisé

Résultats et publication

  • Le pilote finalisé a été publié dans le dépôt GitHub github.com/narqo/freebsd-brcmfmac
  • L’auteur précise qu’il « n’a pas écrit le code lui-même »
  • Quelques problèmes connus subsistent, et il recommande pour l’instant de ne l’utiliser que comme référence pédagogique

3 commentaires

 
heal9179 2026-02-24

Une vraie passoire niveau sécurité~

 
gg5823 2026-02-26

Il aurait dû faire quelque chose comme ça, le renforcer côté sécurité, le faire auditer puis au moins soumettre une PR en amont, ou bien continuer à le renforcer sur son propre GitHub et bien le faire connaître à la communauté BSD ; si ça s’est arrêté là, je doute un peu de la sincérité de la démarche. Si c’est un vrai utilisateur, il comblera manuellement les failles de sécurité ; et si c’est quelqu’un qui utilise très bien Windows et s’amuse avec d’autres OS par hobby, alors il l’abandonnera sans doute. Vu que c’est un modèle de 2016, je pense plutôt que c’est le deuxième cas.

 
GN⁺ 2026-02-24
Commentaires Hacker News
  • À mes yeux, l’idée clé ici est l’approche spec-first
    Dans la génération de code par IA, faire rédiger au modèle une spécification détaillée avant l’implémentation réduit fortement les cycles d’itération
    Sans spécification, le modèle erre entre des approches plausibles, mais avec une bonne spec, il garde une cohérence même sur des milliers de lignes de code
    Les deux mois de développement sont aussi intéressants. C’est pratiquement comme si un nouveau pilote kernel était apparu, donc même avec environ 500 dollars de coûts d’API, l’expérience vaut largement le coup

  • J’ai trouvé marquant le passage où, au lieu de coder, il a ouvert une nouvelle session Pi et demandé à l’agent de rédiger une spécification détaillée du pilote brcmfmac
    Ce type de document de planification (markdown) est vraiment important pour les gros travaux avec des LLM

    • Je pense que la frontière entre le reverse engineering assisté par IA et le blanchiment de licences open source est très mince
      Le cas décrit dans l’article semble avoir franchi cette frontière. Dans une clean room traditionnelle, une équipe ne documente que l’interface, pas le code
  • J’ai eu une expérience similaire. QEMU ne compilait plus sur un ancien MacOS (architecture M1), et en le confiant à Sonnet 4.6, il a rédigé le patch et terminé l’installation en quelques minutes
    Je lui ai seulement dit de regarder les erreurs et de les corriger, et il a tout résolu parfaitement. Honnêtement, sans l’IA, j’aurais probablement simplement abandonné

    • Je me demande quel prompt a été utilisé
    • Je me demande si tu pourrais partager ce code de patch
  • J’ai l’impression qu’on va entrer dans une époque où les gens n’achèteront plus de logiciels, ils les fabriqueront eux-mêmes
    Le filtre anti-spam de Thunderbird était cassé, donc j’en ai refait un moi-même, et il fonctionne bien mieux
    Si un CRM n’a pas la fonction qu’on veut, il suffira de la créer soi-même. Il va devenir facile de concevoir et déployer des solutions sur mesure pour résoudre ses propres problèmes

    • En pratique, je pense que seule une partie des gens fera ça. Surtout ceux qui aimaient déjà fabriquer des choses
      Les personnes non techniques, comme dans ma famille, continueront à utiliser l’App Store ou des sites web
    • Ça ressemble un peu à ce qu’on disait à l’arrivée des imprimantes 3D : « maintenant on n’achètera plus d’objets, on les imprimera nous-mêmes »
      Les logiciels standardisés ont aussi de gros avantages. Les entreprises peuvent recruter des gens qui connaissent déjà des outils familiers comme Photoshop ou Xero
    • Je suis d’accord. Corriger ou patcher soi-même avec l’IA est beaucoup plus rapide que d’ouvrir une issue, soumettre une PR et attendre une review
    • Ce que je veux, c’est la capacité de modifier un logiciel existant avec l’IA. Je le voulais déjà avant, mais maintenant les plugins pourraient redevenir à la mode
    • Mais c’est une vision un peu naïve. La plupart des gens ne sont pas sur HN. Il faudrait aussi entendre les avis en dehors de la communauté tech
  • On dirait que le support matériel va bientôt être complètement résolu sur tous les OS
    Les agents de code IA progressent au point de pouvoir produire un pilote pour presque n’importe quel appareil
    À moins que le fabricant ne cache volontairement l’interface, le support BSD ou Linux suivra naturellement

    • Si cela a été possible, c’est parce que Claude s’est appuyé sur le pilote Linux. Sans code existant, l’IA a du mal à comprendre seule le matériel
    • On en est encore loin. En réalité, il s’agissait de convertir un pilote Linux pour FreeBSD, et l’IA n’a pas réussi à tout faire seule.
      Au contraire, le rôle humain de pilotage et de vérification est devenu encore plus important
    • On a maintenant l’impression que même les contraintes de la GPL deviennent inopérantes face à l’IA
    • Certains pilotes sont simples, mais d’autres sont des travaux complexes qui prennent plus de six mois à une équipe
    • Dire que « l’IA peut produire tous les pilotes » est une idée beaucoup trop simpliste. En pratique, leur stabilité n’est pas prouvée, et ils ne remplacent pas encore les pilotes propriétaires
  • Le logiciel est en train de dévorer le monde encore plus vite
    Désormais, des logiciels vibe-coded vont apparaître partout, et les gens les utiliseront sans trop se poser de questions
    Le problème, c’est qu’on pourrait aussi voir sortir du code contenant des malwares. Qui va tout vérifier ?

    • Je pense qu’il y aura de plus en plus de logiciels jetables
      Par exemple, si je veux acheter des billets de concert, un agent IA pourra générer et exécuter du code à la volée
      Si je recommence l’année suivante, il régénérera un nouveau code adapté à la version de l’API
      Ça peut sembler du gaspillage, mais c’est une structure bien plus dynamique et flexible
      Au final, le fournisseur n’aura qu’à proposer une API, et l’utilisateur pourra avoir sa propre UI
    • Au bout du compte, les gens finiront par distinguer les domaines où l’IA peut générer et exécuter en toute sécurité, et ceux qu’il faut vérifier soi-même
      Par exemple, je peux confier à l’IA mon application de gestion de collection de jeux de société, mais pour tout ce qui touche à la finance ou à la sécurité, j’utiliserai des logiciels conçus par des experts
  • Un module kernel généré par IA est chargé en ring 0, et son auteur précise lui-même qu’il est plein de problèmes et ne doit pas être utilisé en production
    On a l’impression de traverser à toute vitesse une époque « intrinsèquement peu sûre »

    • Si j’étais une superintelligence, j’essaierais probablement de m’échapper via le pilote Wi-Fi
    • Voilà ce qui arrive quand le fabricant ne fournit ni pilote open source ni documentation
      C’est malgré tout mieux que de ne rien faire, et comme le code est public, on peut aussi l’améliorer
    • La sécurité est importante, mais il faut aussi préserver la liberté d’expérimenter et de partager
      Tous les projets GitHub n’ont pas besoin d’être des produits commerciaux
  • Ce travail ressemble davantage à un portage s’appuyant sur une implémentation existante
    Il serait intéressant de voir, du point de vue de la GPL, si on parle simplement d’« inspiration » ou d’un vrai travail « dérivé »
    En entreprise aussi, on avance avec assurance quand une implémentation existe déjà, mais ceux qui ouvrent la voie les premiers ne sont pas reconnus à leur juste valeur

  • L’auteur a dit qu’il n’avait pas écrit le code lui-même, qu’il y avait beaucoup de bugs et qu’il fallait voir ça uniquement comme un projet d’apprentissage
    Après trois tentatives sur plusieurs mois, on est juste arrivé à quelque chose qui fonctionne à peu près, mais certains exagèrent déjà en disant que « l’IA a conquis la programmation »
    En réalité, c’est un bon article, mais beaucoup de commentaires l’ont mal compris en ne lisant que le titre

    • L’auteur a aussi dit qu’il ne lisait pas vraiment le code et qu’il s’agissait simplement d’un jouet expérimental
    • C’est encore inachevé aujourd’hui, mais le fait que ce soit désormais possible pour la première fois est l’élément important
      Produire un pilote fonctionnel sans connaissance du matériel ni des pilotes constitue un nouveau jalon
    • Même avec des bugs, il existe très peu de développeurs capables d’écrire un pilote kernel FreeBSD
      Ce type de résultat a une vraie valeur comme point de départ
    • Les programmeurs ont toujours cherché de nouvelles couches d’abstraction. Le codage avec LLM s’inscrit dans cette continuité
    • Dire que « le LLM génère du code à chaque interaction », c’est une illusion efficace, un peu comme l’upscaling GPU
      Au lieu d’un rendu direct en haute résolution, le GPU comble « magiquement » la différence, d’une manière assez comparable
  • J’aimerais qu’il y ait des pilotes récents pour les Mac dans Asahi Linux. Je trouve que c’est un bon exemple d’utilisation pertinente de l’IA

    • Mais chez nous, on interdit la génération de code par IA à cause des problèmes de droits d’auteur
      On ne peut pas exclure que l’IA ait appris à partir de documents ou de binaires Apple, et la compatibilité de licence du code généré n’est pas garantie non plus
    • Comme il n’existe pas de pilotes open source pour Mac, ce sera impossible à moins que l’IA n’observe et comprenne le matériel par elle-même
    • C’est comme se plaindre que « DeLorean n’a pas fabriqué les pièces de la machine à voyager dans le temps »