11 điểm bởi GN⁺ 2026-02-24 | 3 bình luận | Chia sẻ qua WhatsApp
  • Chip Broadcom BCM4350 trên MacBook Pro 2016 không được FreeBSD hỗ trợ mặc định, nên trước đây cách phổ biến là đi đường vòng bằng wifibox thông qua một Linux VM
  • Tác giả đã dùng Claude Code để port driver brcmfmac của Linux sang FreeBSD, nhưng thất bại do kernel panic và các vấn đề tương thích của LinuxKPI
  • Sau đó, tác giả dùng Pi coding agent để phân tích cách brcmfmac hoạt động và để AI viết một bản đặc tả kỹ thuật (specification) gồm 11 chương dành riêng cho BCM4350
  • Sau khi đối chiếu chéo nhiều mô hình AI (Opus, Codex, Gemini, v.v.) để bổ sung bản đặc tả, tác giả đã dùng nó làm nền tảng để tự động tạo hoàn toàn một driver mới cho FreeBSD
  • Kết quả là một kernel module hỗ trợ quét Wi‑Fi, kết nối 2.4/5GHz và xác thực WPA/WPA2, và mã nguồn đã được công khai trên GitHub

Bối cảnh

  • MacBook Pro 2016 dùng chip Wi‑Fi Broadcom BCM4350, nhưng FreeBSD không có driver native cho chip này
    • Trên diễn đàn FreeBSD, cách thường được gợi ý là dùng wifibox để chạy driver brcmfmac thông qua một Linux VM
  • brcmfmac là driver Linux dành cho các chip FullMAC của Broadcom, giao các tác vụ như xử lý frame 802.11 và mã hóa WPA cho firmware bên trong chip
  • Để tạo một module native cho FreeBSD, cần chuyển đổi “glue code” nhằm port một phần mã Linux sang phù hợp với FreeBSD

Màn 1 — Thử nghiệm đầu tiên với Claude Code

  • Tác giả dùng Claude Code để thử chuyển đổi mã brcmfmac cho FreeBSD
    • Tác giả yêu cầu nó tham khảo lớp tương thích LinuxKPI của FreeBSD và làm theo cách của driver iwlwifi dành cho Intel
  • Module biên dịch được nhưng không hoạt động trên phần cứng thật, và gây ra kernel panic
  • Claude đã sửa bằng cách thêm các đoạn #ifdef __FreeBSD__, nhưng vẫn không ổn định do các khiếm khuyết của LinuxKPI
  • AI cảnh báo rằng dự án sẽ trở nên “phức tạp và lộn xộn”, và kết quả cuối cùng chỉ là một đống mã không chạy được

Màn 2 — Cách tiếp cận dựa trên đặc tả

  • Sau đó, tác giả dùng Pi coding agent để phân tích cấu trúc của driver brcmfmac với trọng tâm là BCM4350, rồi tạo một bản đặc tả chi tiết cho triển khai clean-room
  • AI đã tạo ra một tài liệu gồm 11 chương
    • Ví dụ: 00-overview.md, 04-firmware-interface.md, 08-data-path.md v.v.
  • Tác giả dùng mô hình Codex để kiểm chứng và sửa các điểm không khớp giữa bản đặc tả và mã thực tế
  • Tiếp theo, tác giả dùng mô hình Opus để thẩm định lại xem các chỉnh sửa đã khớp với mã hay chưa
  • Sau khi so sánh nhiều mô hình, tác giả nhận xét rằng Gemini 3 Pro preview tạo ra nhiều lỗi (“hallucination”) nhất

Màn 3 — Xây dựng driver FreeBSD mới

  • Dựa trên bản đặc tả, tác giả bắt đầu dự án viết mới một driver FreeBSD cho BCM4350
  • AI đã ghi lại các quyết định thiết kế như cấu trúc dự án, ngôn ngữ (có dùng C hay không), phụ thuộc LinuxKPI và các mốc phát triển
  • Ban đầu dự án dùng LinuxKPI, nhưng về sau chuyển sang mã native của FreeBSD do độ phức tạp tăng lên
  • AI truy cập build host và test VM qua SSH để chạy vòng lặp build và kiểm thử tự động
    • Mỗi khi VM bị crash, hệ thống được cấu hình để tự tóm tắt và ghi lại nguyên nhân
  • Sau nhiều phiên lặp lại, một kernel module có thể quét Wi‑Fi, kết nối 2.4GHz/5GHz và xác thực WPA/WPA2 đã được hoàn thiện

Kết quả và công bố

  • Driver hoàn chỉnh đã được công khai trên kho GitHub github.com/narqo/freebsd-brcmfmac
  • Tác giả khẳng định mình “không trực tiếp viết mã”
  • Vẫn còn một số vấn đề đã biết, và hiện tại tác giả khuyến nghị chỉ nên dùng ở mức tham khảo phục vụ học tập

3 bình luận

 
heal9179 2026-02-24

Lỗ hổng bảo mật toang hoác~

 
gg5823 2026-02-26

Đã làm đến mức đó thì nên gia cố bảo mật, kiểm tra kỹ rồi ít nhất cũng để lại một PR lên upstream, hoặc tiếp tục củng cố trên GitHub của mình và thông báo rộng rãi cho cộng đồng BSD; nếu dừng ở đó thì tôi không rõ mức độ chân thành lắm. Nếu là người dùng thực sự thì sẽ tự vá các lỗ hổng bảo mật, còn nếu là kiểu vẫn dùng Windows là chính rồi lấy các OS khác ra nghịch cho vui như sở thích thì chắc sẽ bỏ bê thôi. Nhìn là đời 2016 nên có vẻ là vế sau.

 
GN⁺ 2026-02-24
Ý kiến trên Hacker News
  • Theo tôi, cách tiếp cận spec-first mới là điểm mấu chốt
    Trong việc tạo mã bằng AI, nếu để mô hình viết một bản đặc tả chi tiết trước khi triển khai thì số vòng lặp sẽ giảm đi rất nhiều
    Nếu bắt đầu mà không có đặc tả, mô hình sẽ loay hoay giữa các cách tiếp cận có vẻ hợp lý; nhưng nếu có đặc tả tốt thì nó có thể giữ được tính nhất quán ngay cả trong hàng nghìn dòng mã
    Khoảng thời gian phát triển hai tháng cũng rất đáng chú ý. Xem như đã có thêm một kernel driver mới, nên nếu phí gọi API vào khoảng 500 USD thì đây vẫn là một thử nghiệm rất đáng giá

  • Tôi ấn tượng với đoạn nói rằng thay vì viết code ngay, họ mở một phiên Pi mới và để agent viết bản đặc tả chi tiết cho driver brcmfmac
    Việc viết ra những tài liệu kế hoạch (markdown) như vậy thực sự rất quan trọng trong các tác vụ lớn với LLM

    • Tôi nghĩ ranh giới giữa reverse engineering có AI hỗ trợ và tẩy rửa giấy phép mã nguồn mở là cực kỳ mong manh
      Trường hợp được mô tả trong bài có vẻ đã vượt qua ranh giới đó. Trong thiết kế clean-room truyền thống, một nhóm sẽ chỉ tài liệu hóa giao diện chứ không phải mã
  • Tôi cũng từng có trải nghiệm tương tự. QEMU không còn biên dịch được trên MacOS cũ (kiến trúc M1), nhưng khi giao cho Sonnet 4.6 thì nó viết patch và hoàn tất cài đặt chỉ trong vài phút
    Tôi chỉ đưa lỗi và bảo nó sửa, vậy mà nó xử lý hoàn hảo. Thật lòng mà nói, nếu không có AI thì chắc tôi đã bỏ cuộc

    • Tôi tò mò bạn đã dùng prompt
    • Tôi cũng muốn biết bạn có thể chia sẻ mã patch đó không
  • Có vẻ chúng ta đang tiến tới một thời đại mà mọi người sẽ không mua phần mềm nữa mà tự làm lấy
    Bộ lọc spam của Thunderbird bị hỏng nên tôi tự làm lại một cái mới và nó hoạt động tốt hơn nhiều
    Nếu CRM không có tính năng bạn muốn thì cứ tự làm. Giờ đây việc tạo và triển khai giải pháp tùy biến để xử lý vấn đề riêng của mình sẽ trở nên dễ dàng

    • Thực tế thì có lẽ chỉ một số người mới làm vậy, cụ thể là những người vốn đã thích tự tạo ra thứ gì đó
      Những người ngoài ngành kỹ thuật như gia đình tôi có lẽ vẫn sẽ dùng App Store hoặc website như trước
    • Chuyện này giống như lúc máy in 3D mới xuất hiện, ai cũng nói rằng “giờ sẽ không cần mua đồ nữa mà tự in ra”
      Phần mềm tiêu chuẩn hóa vẫn có lợi thế lớn. Doanh nghiệp có thể tuyển người đã quen dùng những công cụ phổ biến như Photoshop hay Xero
    • Tôi cũng đồng ý. Tự sửa hoặc vá bằng AI nhanh hơn rất nhiều so với việc tạo issue, mở PR rồi chờ review
    • Điều tôi muốn là khả năng chỉnh sửa phần mềm hiện có bằng AI. Tôi đã muốn điều đó từ lâu, và có lẽ plugin sẽ lại trở nên phổ biến
    • Nhưng đây là một góc nhìn khá ngây thơ. Phần lớn mọi người không ở trên HN. Cũng cần lắng nghe ý kiến từ bên ngoài cộng đồng kỹ thuật
  • Có vẻ sắp tới hỗ trợ phần cứng trên mọi hệ điều hành sẽ được giải quyết hoàn toàn
    Các agent code AI đang tiến bộ đến mức có thể tạo driver cho gần như bất kỳ thiết bị nào
    Trừ khi nhà sản xuất cố tình giấu giao diện, còn không thì hỗ trợ cho BSD hay Linux sẽ tự nhiên xuất hiện theo

    • Lý do việc này khả thi là vì Claude đã tham khảo driver Linux. Nếu không có mã sẵn, AI sẽ khó mà tự mình hiểu được phần cứng
    • Vẫn còn xa lắm. Thực tế đây là công việc chuyển một driver Linux sang FreeBSD, và AI cũng không làm trọn vẹn được.
      Ngược lại, vai trò quản lý và kiểm tra của con người lại càng trở nên quan trọng hơn
    • Giờ thì có cảm giác ngay cả các ràng buộc của GPL cũng trở nên bất lực trước AI
    • Có những driver khá đơn giản, nhưng cũng có loại là công việc phức tạp đến mức cả nhóm phải làm hơn nửa năm
    • Nói rằng “AI có thể làm mọi driver” là một cách nhìn quá đơn giản. Trên thực tế độ ổn định còn chưa được kiểm chứng, và cũng chưa đến mức thay thế được driver đóng
  • Tốc độ phần mềm đang ăn trọn thế giới còn nhanh hơn trước
    Giờ đây phần mềm vibe-coded sẽ mọc lên khắp nơi, và mọi người có lẽ sẽ dùng nó mà không chút nghi ngờ
    Vấn đề là có thể xuất hiện mã lẫn mã độc. Ai sẽ là người kiểm chứng tất cả những thứ đó?

    • Có lẽ sau này sẽ có rất nhiều phần mềm dùng một lần
      Ví dụ, nếu bạn muốn mua vé concert, một agent AI sẽ tạo mã tại chỗ rồi chạy luôn
      Năm sau mua lại thì nó sẽ tái tạo mã mới theo đúng phiên bản API lúc đó
      Trông có vẻ lãng phí, nhưng đó là một cấu trúc động và linh hoạt hơn nhiều
      Cuối cùng bên cung cấp chỉ cần đưa ra API, còn người dùng sẽ có UI của riêng mình
    • Rồi con người sẽ dần phân biệt được đâu là những lĩnh vực có thể an toàn giao cho AI tạo và chạy, và đâu là những lĩnh vực phải tự kiểm chứng trực tiếp
      Ví dụ ứng dụng quản lý bộ sưu tập board game của tôi thì có thể giao cho AI, nhưng các ứng dụng tài chính hoặc bảo mật thì tôi sẽ dùng sản phẩm do chuyên gia làm
  • Kernel module do AI tạo ra được nạp ở ring 0, trong khi chính tác giả cũng nói rõ là “có nhiều vấn đề nên đừng dùng thực tế”
    Cảm giác như chúng ta đang lao qua một “thời đại vốn dĩ đã không an toàn” chỉ vì tốc độ

    • Nếu tôi là một siêu trí tuệ AI thì có lẽ tôi đã thử trốn thoát thông qua driver Wi‑Fi
    • Đây là hệ quả của việc nhà sản xuất không cung cấp driver mã nguồn mở hay tài liệu
      Dù vậy vẫn còn tốt hơn là không làm gì cả, và vì mã đã được công khai nên vẫn có thể tiếp tục cải thiện
    • Bảo mật rất quan trọng, nhưng tự do thử nghiệm và chia sẻ cũng cần thiết
      Không phải mọi dự án GitHub đều cần trở thành sản phẩm thương mại
  • Công việc lần này gần với một bản port tận dụng triển khai sẵn có hơn
    Sẽ thú vị nếu so sánh từ góc nhìn GPL xem nó ở mức “được truyền cảm hứng” hay là mức “dựa trên đó”
    Ở công ty cũng vậy, nếu đã có triển khai sẵn thì mọi người sẽ tự tin tiến hành, còn những người mở đường từ con số 0 lại thường không được ghi nhận đúng mức

  • Tác giả nói rằng mình “không trực tiếp viết code, còn nhiều lỗi, và chỉ nên xem như tài liệu học tập”
    Sau vài tháng và ba lần thử mới đạt tới mức chạy được, nhưng một số người lại phóng đại thành “AI đã chinh phục lập trình”
    Thực ra đây là một bài viết hay, nhưng có rất nhiều bình luận hiểu sai chỉ vì nhìn tiêu đề

    • Tác giả cũng nói rõ là bản thân còn không đọc code cho đàng hoàng, và đây chỉ là một đồ chơi thử nghiệm đơn giản
    • Dù hiện tại còn chưa hoàn thiện, điểm quan trọng là nó đã đạt đến bước đầu tiên khả thi
      Việc tạo ra được một driver hoạt động dù không có kiến thức về phần cứng hay driver vẫn là một cột mốc mới
    • Dù còn lỗi, số lập trình viên có thể viết kernel driver cho FreeBSD là cực kỳ ít
      Một kết quả như thế này có ý nghĩa rất lớn như một điểm khởi đầu
    • Lập trình viên từ trước đến nay vẫn luôn đi tìm những tầng trừu tượng mới. Việc code bằng LLM chỉ là phần tiếp nối của dòng chảy đó
    • Câu nói “LLM tạo mã ở mỗi lần tương tác” là một ảo tưởng hiệu quả, gần giống như GPU upscaling
      Thay vì render trực tiếp ở độ phân giải cao, GPU sẽ “ảo diệu” lấp đầy phần chênh lệch — khá giống với cách này
  • Sẽ thật tuyệt nếu có driver mới cho Mac hiện đại phục vụ Asahi Linux. Tôi nghĩ đây là một ví dụ sử dụng AI khá tốt

    • Nhưng chúng tôi cấm tạo mã bằng AIvấn đề bản quyền
      Không thể loại trừ khả năng AI đã học từ tài liệu hoặc binary của Apple, và cũng không thể đảm bảo tính tương thích giấy phép của mã được sinh ra
    • Vì Mac không có driver mã nguồn mở, nên điều đó là bất khả thi trừ khi AI có thể tự quan sát và hiểu phần cứng
    • Chuyện này giống như than phiền rằng “DeLorean không làm sẵn linh kiện cho cỗ máy thời gian