- ชิป Broadcom BCM4350 ใน MacBook Pro รุ่นปี 2016 ยังไม่ได้รับการรองรับโดยตรงใน FreeBSD ดังนั้นก่อนหน้านี้วิธีที่ใช้กันทั่วไปคือ การอ้อมผ่าน wifibox โดยใช้ Linux VM
- ผู้เขียนพยายามพอร์ตไดรเวอร์ brcmfmac ของ Linux มายัง FreeBSD ด้วย Claude Code แต่ล้มเหลวเพราะเกิดเคอร์เนลแพนิกและมี ปัญหาความเข้ากันได้ของ LinuxKPI
- หลังจากนั้นจึงใช้ Pi coding agent วิเคราะห์หลักการทำงานของ brcmfmac และให้ AI เขียน สเปกทางเทคนิค 11 บท สำหรับ BCM4350 โดยเฉพาะ
- หลังตรวจสอบไขว้และปรับปรุงสเปกด้วย AI หลายโมเดล (Opus, Codex, Gemini ฯลฯ) ก็ใช้สเปกนั้นเป็นฐานในการ สร้างไดรเวอร์ใหม่สำหรับ FreeBSD แบบอัตโนมัติทั้งหมด
- ผลลัพธ์คือเคอร์เนลโมดูลที่รองรับ การสแกน Wi‑Fi, การเชื่อมต่อ 2.4/5GHz, การยืนยันตัวตน WPA/WPA2 และโค้ดได้เปิดเผยบน GitHub
พื้นหลัง
- MacBook Pro รุ่นปี 2016 ใช้ ชิป Wi‑Fi Broadcom BCM4350 แต่ FreeBSD ไม่มีไดรเวอร์เนทีฟสำหรับชิปรุ่นนี้
- ในฟอรัมของ FreeBSD มักแนะนำวิธีใช้ไดรเวอร์ brcmfmac ผ่าน Linux VM ที่ชื่อ wifibox
- brcmfmac คือไดรเวอร์ Linux สำหรับชิป FullMAC ของ Broadcom ซึ่งมอบหมายงานอย่างการประมวลผลเฟรม 802.11 และการเข้ารหัส WPA ให้กับเฟิร์มแวร์ภายในชิป
- หากต้องการสร้างโมดูลเนทีฟสำหรับ FreeBSD จำเป็นต้องมีการแปลง “glue code” เพื่อพอร์ตบางส่วนของโค้ด Linux ให้เข้ากับ FreeBSD
Act 1 — ความพยายามครั้งแรกด้วย Claude Code
- ผู้เขียนใช้ Claude Code เพื่อพยายามแปลงโค้ด brcmfmac ให้ใช้กับ FreeBSD
- โดยอ้างอิงเลเยอร์ความเข้ากันได้ LinuxKPI ของ FreeBSD และขอให้ทำตามแนวทางของไดรเวอร์ Intel iwlwifi
- โมดูลสามารถคอมไพล์ได้ แต่ไม่ทำงานบนฮาร์ดแวร์จริงและเกิด เคอร์เนลแพนิก
- Claude ปรับแก้ด้วยการเพิ่มเงื่อนไข
#ifdef __FreeBSD__ แต่ก็ยังไม่เสถียรเนื่องจาก ข้อบกพร่องของ LinuxKPI
- AI เตือนว่าโปรเจ็กต์นี้ “จะซับซ้อนและเละเทะ” และท้ายที่สุดก็เหลือเพียง โค้ดที่ใช้งานไม่ได้
Act 2 — แนวทางที่อิงจากสเปก
- ต่อมาจึงใช้ Pi coding agent วิเคราะห์โครงสร้างของไดรเวอร์ brcmfmac โดยโฟกัสที่ BCM4350 และให้เขียน สเปกแบบละเอียดสำหรับการทำ clean-room implementation
- AI สร้างเอกสารที่ประกอบด้วย 11 บท
- ตัวอย่างเช่น
00-overview.md, 04-firmware-interface.md, 08-data-path.md เป็นต้น
- ผู้เขียนใช้ โมเดล Codex เพื่อตรวจสอบและแก้ไขความไม่ตรงกันระหว่างสเปกกับโค้ดจริง
- จากนั้นใช้ โมเดล Opus ตรวจทานซ้ำเพื่อยืนยันว่าการแก้ไขสอดคล้องกับโค้ด
- เมื่อเปรียบเทียบหลายโมเดล ผู้เขียนระบุว่า Gemini 3 Pro preview มีข้อผิดพลาดแบบ “hallucination” มากที่สุด
Act 3 — สร้างไดรเวอร์ FreeBSD ใหม่
- จากสเปกดังกล่าว ได้เริ่มโปรเจ็กต์ เขียนไดรเวอร์ FreeBSD ใหม่สำหรับ BCM4350
- AI จัดทำเอกสารการตัดสินใจด้านการออกแบบ เช่น โครงสร้างโปรเจ็กต์ ภาษา (จะใช้ C หรือไม่), การพึ่งพา LinuxKPI และมิลสโตนต่าง ๆ
- ในช่วงแรกยังใช้ LinuxKPI แต่ภายหลังเปลี่ยนเป็น โค้ด FreeBSD แบบเนทีฟ เพราะความซับซ้อนเพิ่มขึ้น
- AI เข้าถึง build host และ test VM ผ่าน SSH เพื่อทำ ลูปการบิลด์และทดสอบแบบอัตโนมัติ
- และตั้งค่าให้สรุปและบันทึกสาเหตุทุกครั้งที่ VM แครช
- หลังผ่านการทำงานแบบวนซ้ำหลายเซสชัน ในที่สุดก็ได้เคอร์เนลโมดูลที่รองรับ การสแกน Wi‑Fi, การเชื่อมต่อ 2.4GHz/5GHz, การยืนยันตัวตน WPA/WPA2
ผลลัพธ์และการเผยแพร่
- ไดรเวอร์ที่เสร็จสมบูรณ์ถูกเผยแพร่ใน GitHub repository github.com/narqo/freebsd-brcmfmac
- ผู้เขียนระบุชัดเจนว่า “ไม่ได้เขียนโค้ดด้วยตัวเอง”
- ยังมีปัญหาที่ทราบอยู่บางส่วน และขณะนี้แนะนำให้ใช้เพียง ในระดับอ้างอิงเพื่อการเรียนรู้ เท่านั้น
3 ความคิดเห็น
ช่องโหว่ด้านความปลอดภัยเพียบ~
ควรทำให้มันออกมาแบบนั้น เสริมความปลอดภัย ตรวจทาน แล้วอย่างน้อยก็ฝาก PR ไว้ที่อัปสตรีม หรือไม่ก็เสริมให้แข็งแรงขึ้นต่อใน GitHub ของตัวเองแล้วบอกให้คอมมูนิตี้ BSD รู้กันดี ๆ แต่ถ้าจบแค่นั้น ผมก็ยังไม่ค่อยแน่ใจในความจริงใจนะครับ ถ้าเป็นผู้ใช้จริงก็คงอุดช่องโหว่ด้านความปลอดภัยด้วยตัวเอง และถ้าเป็นคนที่ใช้ Windows เป็นหลักอยู่แล้วแล้วมาเล่น OS อื่นเป็นงานอดิเรก ก็คงปล่อยทิ้งไปมากกว่า ดูจากที่เป็นรุ่นปี 2016 ก็น่าจะเป็นอย่างหลัง
ความคิดเห็นจาก Hacker News
สำหรับผม ประเด็นสำคัญคือแนวทางแบบ spec-first
ในการให้ AI สร้างโค้ด ถ้าให้โมเดลเขียนสเปกที่ละเอียดก่อนลงมือพัฒนา วงจรการลองผิดลองถูกจะสั้นลงมาก
ถ้าเริ่มโดยไม่มีสเปก โมเดลจะวกวนอยู่ระหว่างแนวทางที่ดูเข้าท่าหลายแบบ แต่ถ้ามีสเปกที่ดี ก็จะรักษาความสอดคล้องได้แม้ในโค้ดระดับหลายพันบรรทัด
ระยะเวลาพัฒนาสองเดือนก็น่าสนใจเหมือนกัน เท่ากับมีเคอร์เนลไดรเวอร์ตัวใหม่เกิดขึ้น ถ้าค่าเรียก API อยู่ราว 500 ดอลลาร์ ก็ถือว่าเป็นการทดลองที่คุ้มค่า
ผมประทับใจตรงที่แทนที่จะเขียนโค้ดเลย เขากลับเปิด Pi session ใหม่ แล้วให้เอเจนต์เขียนสเปกอย่างละเอียดของไดรเวอร์ brcmfmac
การเขียน เอกสารแผนงาน (markdown) แบบนี้สำคัญมากจริง ๆ สำหรับงานใหญ่กับ LLM
กรณีที่อธิบายในบทความนี้ดูเหมือนจะข้ามเส้นนั้นไปแล้ว ในการออกแบบแบบคลีนรูมดั้งเดิม ทีมหนึ่งจะทำเอกสารเฉพาะ อินเทอร์เฟซ โดยไม่แตะตัวโค้ด
ผมก็มีประสบการณ์คล้ายกัน QEMU คอมไพล์บน MacOS รุ่นเก่า (สถาปัตยกรรม M1) ไม่ได้อีกต่อไป แต่พอโยนให้ Sonnet 4.6 มันก็เขียนแพตช์และติดตั้งเสร็จภายในไม่กี่นาที
ผมแค่บอกให้มันดูข้อผิดพลาดแล้วแก้ให้ แต่กลับแก้ได้สมบูรณ์แบบ พูดตรง ๆ ถ้าไม่มี AI ผมคงยอมแพ้ไปแล้ว
ต่อไปน่าจะเป็นยุคที่ผู้คนไม่ซื้อซอฟต์แวร์ แต่สร้างใช้เองมากขึ้น
ตัวกรองสแปมของ Thunderbird พัง ผมเลยทำใหม่เอง แล้วมันทำงานดีกว่าเดิมมาก
ถ้า CRM ไม่มีฟีเจอร์ที่ต้องการ ก็สร้างเองได้ ตอนนี้เรากำลังจะเข้าสู่ช่วงที่การสร้างและปล่อย โซลูชันเฉพาะทาง เพื่อแก้ปัญหาของตัวเองทำได้ง่ายขึ้นมาก
คนในครอบครัวผมที่ไม่ได้ทำงานสายเทคนิค ก็คงยังใช้แอปสโตร์หรือเว็บไซต์เหมือนเดิม
ซอฟต์แวร์มาตรฐานก็ยังมีข้อดีมาก บริษัทสามารถจ้างคนที่ใช้เครื่องมือที่คุ้นเคยอยู่แล้วอย่าง Photoshop หรือ Xero ได้
อีกไม่นาน การรองรับฮาร์ดแวร์ บนทุก OS น่าจะถูกแก้ได้หมด
เอเจนต์เขียนโค้ด AI กำลังก้าวไปถึงจุดที่สามารถสร้างไดรเวอร์ให้กับอุปกรณ์แทบทุกชนิดได้
ตราบใดที่ผู้ผลิตฮาร์ดแวร์ไม่ได้จงใจซ่อนอินเทอร์เฟซ การรองรับบน BSD หรือ Linux ก็น่าจะตามมาเอง
กลับกัน บทบาทของมนุษย์ในฐานะผู้ กำกับดูแลและตรวจทาน กลับสำคัญกว่าเดิม
ซอฟต์แวร์กำลังกินโลกเร็วขึ้นกว่าเดิม
ตอนนี้ซอฟต์แวร์แบบ vibe-coded จะโผล่ขึ้นมาทั่วไป และผู้คนก็น่าจะใช้งานมันโดยแทบไม่ตั้งคำถาม
ปัญหาคืออาจมีมัลแวร์ปะปนอยู่ในโค้ดได้ แล้วใครจะเป็นคนตรวจสอบทั้งหมดนั้น?
เช่น ถ้าอยากซื้อตั๋วคอนเสิร์ต เอเจนต์ AI ก็จะสร้างและรันโค้ดสด ๆ ตรงนั้นเลย
ปีถัดไปถ้าจะซื้ออีก ก็แค่สร้างโค้ดใหม่ให้ตรงกับเวอร์ชัน API ตอนนั้น
มันอาจดูสิ้นเปลือง แต่เป็นโครงสร้างที่ ไดนามิกและยืดหยุ่น กว่ามาก
สุดท้ายผู้ขายแค่ต้องมี API ส่วนผู้ใช้ก็มี UI ของตัวเองได้
เช่น แอป จัดการคอลเลกชันบอร์ดเกม ของผมอาจปล่อยให้ AI ทำได้ แต่ถ้าเป็นแอปด้านการเงินหรือความปลอดภัย ผมจะใช้ของที่ผู้เชี่ยวชาญสร้าง
เคอร์เนลโมดูลที่ AI สร้าง ถูกโหลดใน ring 0 และคนทำเองก็ยังบอกว่า “มีปัญหาเยอะ ห้ามใช้จริง”
มันให้ความรู้สึกเหมือนเรากำลังเร่งความเร็วฝ่าช่วงเวลาแห่ง “ความไม่ปลอดภัยโดยปริยาย”
ถึงอย่างนั้นมันก็ยังดีกว่าไม่ทำอะไรเลย และเพราะเปิดเผยโค้ดไว้ คนอื่นก็ช่วยกันปรับปรุงต่อได้
ไม่ใช่ว่าทุกโปรเจกต์บน GitHub จำเป็นต้องเป็นผลิตภัณฑ์เชิงพาณิชย์
งานครั้งนี้ใกล้เคียงกับ การพอร์ตงานเดิม มากกว่าการสร้างใหม่
ถ้ามองจากมุม GPL ก็น่าสนใจว่าจะถือเป็นแค่ “แรงบันดาลใจ” หรือเป็น “งานที่อิงจากของเดิม”
ในบริษัทก็เหมือนกัน ถ้ามี implementation เดิมอยู่แล้ว ทุกคนจะเดินหน้าอย่างมั่นใจ แต่คนที่ บุกเบิกเส้นทางใหม่ มักไม่ได้รับการยกย่อง
ผู้เขียนบอกเองว่า “ไม่ได้เขียนโค้ดด้วยตัวเอง มีบั๊กเยอะ และควรมองเป็นงานเพื่อการเรียนรู้เท่านั้น”
กว่าจะพอใช้งานได้ก็ต้องลองถึงสามครั้งในช่วงหลายเดือน แต่บางคนกลับพูดเกินจริงว่า “AI พิชิตการเขียนโปรแกรมแล้ว”
จริง ๆ แล้วเป็นบทความที่ดี แต่มี คอมเมนต์ที่เข้าใจผิดจากการอ่านแค่พาดหัว อยู่เยอะมาก
การสร้างไดรเวอร์ที่ใช้งานได้โดยแทบไม่มีความรู้ด้านฮาร์ดแวร์หรือไดรเวอร์มาก่อน ถือเป็นหมุดหมายใหม่
ผลลัพธ์แบบนี้จึงมีความหมายมากในฐานะจุดเริ่มต้น
แทนที่จะเรนเดอร์ทุกอย่างที่ความละเอียดสูงโดยตรง GPU จะเติมส่วนต่างให้ดูสมจริงอย่างน่าอัศจรรย์
คงดีถ้ามีไดรเวอร์ Mac รุ่นใหม่สำหรับ Asahi Linux เกิดขึ้น นี่ถือเป็นตัวอย่างของการใช้ AI ได้ดี
เราไม่อาจตัดความเป็นไปได้ที่ AI จะเคยเรียนรู้จากเอกสารหรือไบนารีของ Apple ได้ และก็ไม่อาจรับประกัน ความเข้ากันได้ของใบอนุญาต ของโค้ดที่สร้างขึ้น