โปรเจกต์ Python-BPF เผชิญคำถามทางเทคนิคแม้จะมีแนวทางการพัฒนา eBPF ที่น่าสนใจ

ไลบรารี Python ใหม่ที่เรียกว่า Python-BPF ได้เกิดขึ้น โดยสัญญาว่าจะให้นักพัฒนาเขียนโปรแกรม eBPF ได้โดยตรงใน Python แทนที่จะต้องฝังโค้ด C ในสตริง อย่างไรก็ตาม โปรเจกต์นี้กำลังได้รับการตรวจสอบทางเทคนิคจากชุมชนนักพัฒนาเกี่ยวกับรายละเอียดการใช้งานและความชัดเจนของเอกสารประกอบ

การติดตั้งและสถานะ:

• สามารถติดตั้งได้ผ่าน pip install pythonbpf
• สถานะโครงการ: ยังไม่พร้อมสำหรับการใช้งานจริง
• ที่มา: โครงการจาก Hackathon
• ความพร้อมใช้งาน: โอเพนซอร์สบน GitHub และ PyPI

ชุมชนตั้งคำถามเกี่ยวกับการใช้งาน

นักพัฒนากำลังตั้งคำถามเกี่ยวกับคำอธิบายทางเทคนิคที่ผู้สร้าง Python-BPF ให้มา เอกสารประกอบของโปรเจกต์อธิบายกระบวนการคอมไพล์แบบสี่ขั้นตอน แต่สมาชิกในชุมชนพบว่าคำอธิบายนั้นสับสนและอาจไม่ถูกต้อง นักพัฒนาคนหนึ่งชี้ให้เห็นว่าขั้นตอนที่ 3 และ 4 ดูเหมือนจะอธิบายกระบวนการเดียวกัน - การแปลง LLVM IR เป็น BPF bytecode - ซึ่งทำให้เกิดคำถามเกี่ยวกับการใช้งานจริง

ส่วน How it works under the hood ทำให้เกิดคำถามมากกว่าที่จะตอบ ความแตกต่างระหว่างขั้นตอนที่ 3 และขั้นตอนที่ 4 คืออะไร ตามที่อธิบาย ขั้นตอนที่ 3 จะไปจาก LLVM IR ไปเป็น BPF (ผ่าน llc) และขั้นตอนที่ 4 - ไปจาก LLVM IR ไปเป็น eBPF bytecode? นั่นไร้สาระ

ความสับสนเกิดจากการอ้างของโปรเจกต์ว่าใช้ทั้ง LLC compiler และ LLVM backend ในขั้นตอนแยกกัน ในขณะที่โดยปกติแล้วสิ่งเหล่านี้จะทำงานร่วมกันในเฟสการคอมไพล์เดียว

กระบวนการคอมไพล์ (ตามที่อธิบายไว้):

1. สร้าง AST โดยใช้โมดูล ast ของ Python
2. ส่งออก LLVM IR โดยใช้ livnite ของ Numba
3. คอมไพล์ LLVM IR โดยใช้ llc -march=bpf -O2
4. สร้างไฟล์ออบเจ็กต์ eBPF ที่มี bytecode

ปัญหาเอกสารประกอบและการเข้าถึง

นอกเหนือจากข้อกังวลทางเทคนิค ความคิดเห็นจากชุมชนยังเน้นปัญหาการนำเสนอ นักพัฒนาหลายคนสังเกตว่าโปรเจกต์ขาดการอธิบายที่เหมาะสมว่า eBPF คืออะไรจริงๆ และทำไมคนถึงอยากใช้มัน เอกสารประกอบสมมติว่าผู้อ่านเข้าใจเทคโนโลยี Berkeley Packet Filter และการประยุกต์ใช้ในการเขียนโปรแกรมเคอร์เนลอยู่แล้ว

นักวิจารณ์ยังชี้ให้เห็นปัญหาการจัดรูปแบบพื้นฐาน เช่น การวางสรุปไว้ที่ท้ายแทนที่จะเป็นจุดเริ่มต้น ทำให้ผู้อ่านเข้าใจวัตถุประสงค์ของโปรเจกต์ได้ยากขึ้น

การเปรียบเทียบกับโซลูชันที่มีอยู่

การอภิปรายเผยให้เห็นว่า Python-BPF ไม่ใช่ความพยายามเดียวที่จะนำ eBPF มาสู่ภาษาระดับสูง สมาชิกในชุมชนแบ่งปันตัวอย่างของโปรเจกต์ที่คล้ายกันในสภาพแวดล้อมการเขียนโปรแกรมอื่นๆ รวมถึงการใช้งานใน Java และโปรเจกต์ Facebook Research ก่อนหน้านี้ที่เรียกว่า py2bpf ที่ใช้แนวทางแตกต่างโดยแปล Python bytecode โดยตรงเป็นคำสั่ง BPF

การเปรียบเทียบเหล่านี้บ่งบอกว่าแม้แนวทางแบบ decorator ของ Python-BPF จะน่าสนใจ แต่ความท้าทายในการคอมไพล์ภาษาระดับสูงเป็น eBPF ได้ถูกแก้ไขมาก่อนแล้วด้วยระดับความสำเร็จที่แตกต่างกัน

คุณสมบัติปัจจุบันของ Python-BPF :

• รองรับการควบคุมการไหลของโปรแกรม
• Hash maps (วางแผนจะรองรับ map ประเภทอื่นๆ)
• การดำเนินการแบบไบนารี
• ฟังก์ชันช่วยเหลือสำหรับการจัดการ map
• ฟังก์ชันการพิมพ์ trace ของ kernel
• ตัวช่วยเหลือเกี่ยวกับ timestamp
• ตัวแปรส่วนกลาง (ดำเนินการผ่าน maps)

ข้อกังวลเรื่องความพร้อมสำหรับการใช้งานจริง

ผู้สร้าง Python-BPF เองก็ยอมรับข้อจำกัดที่สำคัญ โดยอธิบายโค้ดของพวกเขาว่า hacky at best with more bugs than I could count เนื่องจากมีต้นกำเนิดจากโปรเจกต์ hackathon การยอมรับนี้ รวมกับคำถามทางเทคนิคจากชุมชน ทำให้เกิดข้อกังวลเกี่ยวกับความพร้อมของโปรเจกต์สำหรับงานพัฒนาที่จริงจัง

แม้ว่าแนวคิดของการเขียนโปรแกรม eBPF ใน Python แท้ๆ โดยใช้ decorator จะแสดงให้เห็นถึงความหวัง แต่การใช้งานปัจจุบันดูเหมือนจะต้องการการทำงานอย่างมากก่อนที่จะสามารถแข่งขันกับเครื่องมือที่มีชื่อเสียงอย่าง BCC หรือการพัฒนา C แบบดั้งเดิมสำหรับการเขียนโปรแกรม eBPF

eBPF (extended Berkeley Packet Filter) เป็นเทคโนโลยีที่อนุญาตให้โปรแกรมขนาดเล็กทำงานในเคอร์เนล Linux เพื่อตอบสนองต่อเหตุการณ์ ใช้กันทั่วไปสำหรับการตรวจสอบ เครือข่าย และแอปพลิเคชันความปลอดภัย

อ้างอิง: PythonBPF - Writing eBPF Programs in Pure Python