เมื่อไม่นานมานี้ ลินุสได้ตัดสินใจถอดไดรเวอร์ Philips-based USB webcam ออกจากลินุกซ์ เคอร์เนลเวอร์ชันถัดไปอาจจะไม่สนับสนุนเว็บแคมที่ใช้ชิปของ Philips แล้ว … เรื่องนี้ส่งผลกระทบต่อผู้ใช้เต็มๆ เลยกลายเป็นเรื่องที่วิพากษ์วิจารณ์กันเยอะทีเดียว

เรื่องของเรื่องก็คือไดรเวอร์ตัวนี้มันไม่โอเพ่นซอร์ส หรืออาจจะเรียกว่ากึ่งโอเพ่นซอร์ส .. ไดรเวอร์นี้ประกอบด้วยสองส่วนคือ PWCX ที่เป็นโค้ดของไดรเวอร์ พัฒนาโดย Nemosoft Unv. โค้ดส่วนนี้ไม่ได้โอเพ่นซอร์สเพราะติด NDA (Non-Disclosure Agreement) ทาง Nemosoft จึงจำต้องเผยแพร่เป็นไบนารีเพียงอย่างเดียว เมื่อเปิดเผยไม่ได้ PWCX จึงไม่สามารถอยู่ในเคอร์เนลได้ .. เพื่อแก้ปัญหาเรื่องนี้จึงมีโค้ดส่วน PWC ทำหน้าที่เป็นจุดเชื่อม หรือ ‘hook’ ให้กับ PWCX โดย PWC เผยแพร่ด้วย GPL และอยู่ในเคอร์เนลของลินุกซ์ .. โค้ด PWC เป็นไดรเวอร์ทำงานด้วยตัวมันเองได้ แต่จำกัดมากๆ และในความเป็นจริง PWC ไม่ได้เขียนเป็นไดรเวอร์ แต่ใช้เพื่อเป็น hook โดยเฉพาะ .. การทำ hook สำหรับไดรเวอร์แบบไบนารีในเคอร์เนลถือเป็นเรื่องที่ยอมรับไม่ได้ เพราะทำให้เคอร์เนลไม่ ‘สะอาด’ จริง .. เมื่อเป็นเช่นนั้น Greg Kroah (USB maintainer) จึงตัดโค้ดส่วนของ hook ใน PWC ออก (เน้น: ตัดโค้ดของ hook .. ไม่ใช่ตัด PWC) ทำให้ต่อไป PWC จะไม่สามารถโหลด PWCX มาใช้งานได้ .. Nemosoft เห็นเช่นนั้นก็มีท่าทีที่ไม่พอใจเท่าไหร่นัก จึงตัดสินใจหยุดพัฒนาไดรเวอร์นี้ทั้ง PWC/PWCX และขอให้ถอด PWC ออกจากเคอร์เนล .. และลินุสก็ทำตามประสงค์ของ Nemosoft

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

1. PWC เรียกว่าเป็น hook-only for binary-only driver ซึ่งทำให้เคอร์เนลไม่เสรี/โอเพน
2. ไม่มีคนรับดูแล PWC ต่อจาก Nemosoft และ
3. ลินุสถือว่า Nemosoft เป็นเจ้าของโค้ด PWC/PWCX เมื่อเจ้าของไม่ต้องการให้โค้ดอยู่ในเคอร์เนล ก็ถือว่าเป็นเรื่องใหญ่และควรจะให้เกียรติทำตามความต้องการ ถึงแม้ว่าในความเป็นจริงแล้วไม่มีใครเป็นเจ้าของโค้ดนี้ตั้งแต่แปะคำว่า GPL ..

เหตุผลที่ลินุสเน้นย้ำที่สุดคือข้อ 3 นี่แหละ ..

ใครถูกใครผิดก็ไม่รู้เหมือนกัน สำหรับผม เรื่องโอเพนซอร์สมีความสำคัญเหนือกว่าเรื่องเอาใจผู้ใช้เสมอ ไม่ว่าน้ำหนักผู้ใช้จะกดดันขนาดไหน แต่ถ้าทำให้โอเพนซอร์สไม่สะอาดเมื่อไหร่ คำว่า ‘โอเพน’ หรือ ‘ฟรี’ (as in free speech) จะไม่มีความหมายอีกเลย หากหลักการนี้ล้ม ปัญหาจะตามมาหลังจากนั้นอีกเยอะมาก ไม่เพียงเรื่องแนวคิดของโอเพน/ฟรีจะเสียไป แต่ในแง่เทคนิคก็จะเสียไปด้วย การที่มันโอเพน/ฟรีทำให้ลินุกซ์ก้าวไปได้เร็วและมั่นคง เพราะทุกคนเห็นซอร์ส ทุกคนสามารถช่วยกันแก้ไข ทุกคนสามารถช่วยปรับปรุงให้มันดีขึ้นได้ การปกปิดซอร์สทำให้ไม่สามารถคงสภาพการทำงานแบบนี้ได้อีก เสถียรภาพ และความปลอดภัยย่อมลดน้อยลง หากเกิดขึ้นกับเคอร์เนลก็คงไม่ใช่เรื่องดี

ทางออกสำหรับเรื่องนี้ ให้สวยที่สุดคือพัฒนาไดรเวอร์ที่เป็นโอเพนซอร์ส ถ้าทำไม่ได้จริงๆ ก็ย้ายส่วนไบนารีไปอยู่นอกเคอร์เนล หรือทำไดรเวอร์โมดูลที่ไม่ต้องใช้ hook ในเคอร์เนล ..

.. สุดท้ายจะออกมายังไง คงต้องติดตามดูกันต่อไป

เมื่อวาน blog เรื่องเคอร์เนลแพตช์ของ mm และ ck ไปแล้ว ยังมีแพตช์เคอร์เนลอีกหลายตัว แต่ละตัวก็ maintain tree ของตัวเอง มีจุดประสงค์ในการใช้ต่างๆ กันไป สรุปมาให้อ่านกัน:

• aa tree ของ Andrea Arcangeli เน้นเรื่อง VM เป็นหลัก .. aa tree merge เข้าเคอร์เนลตั้งแต่ 2.4.10 .. VM ของเคอร์เนล 2.6 ก็มีพื้นฐานมาจาก aa tree
• ac tree ของ Alan Cox .. Alan เป็น kernel maintainer ตั้งแต่ปลาย 2.0 2.2 เลยมาถึง 2.4 ช่วงต้นๆ ทุกคนยกย่องให้เป็นมือขวาของ Linus .. หลังวางมือ Alan ก็ยังมีส่วนช่วยงานเคอร์เนลอยู่อย่างต่อเนื่อง โดย maintain ac tree ที่มีฟีเจอร์ใหม่ๆ ที่ไม่อยู่ในวานิลลา .. ac tree ยังนับเป็นการทดสอบ bugfix และฟีเจอร์ ก่อนจะส่งให้ Marcello Tosatti (2.4 kernel maintainer ต่อจาก Alan) อีกทีด้วย .. ac patch หายร่วมปีแล้ว เพราะ Alan หยุดงานเคอร์เนลชั่วคราวไปเรียนต่อด้านบริหาร
• bk tree เป็น snapshot จากโค้ดล่าสุดที่ merge เข้าเคอร์เนล .. ชื่อ bk มาจาก BitKeeper ซึ่งเป็นซอฟต์แวร์ SCM ที่ใช้ในการจัดการโค้ดของเคอร์เนลทั้งหมด คล้ายๆ CVS, SVN .. ลินุสเลือกใช้ BitKeeper เพราะสะดวกในการจัดการ changeset มากกว่าตัวอื่น .. BitKeeper เป็น commercial software แต่โครงการโอเพนซอร์สใช้งานได้ฟรี (as in free beer)
• ck tree ของ Con Kolivas .. Con รวบรวมแพตช์เพื่องานเดสก์ท็อป/interactive/low latency เป็นหลัก และยังแฮ็ก scheduling ในเคอร์เนลให้เหมาะกับงานเดสก์ท็อป สมัยนึง ck tree เป็นแพตช์เซ็ตที่ทำงานเร็วกว่าวานิลลาจนรู้สึกได้
• mm tree ของ Andrew Morton .. ตอนจะรีลีส 2.6 Linus ชวนให้ Andrew มาช่วย maintain kernel แต่ Andrew ก็แบ่งรับแบ่งสู้ สุดท้ายแล้ว Linus เลยเป็นคน maintain อย่างเป็นทางการ ในขณะที่ Andrew ช่วยรวบรวมแพตช์และแยก mm tree ไว้เพื่อให้ทดสอบกันในทำนองเดียวกับ ac tree / 2.4

นอกจาก tree ยอดนิยมข้างบนนี้ ก็ยังมี patch/patchset อีกเยอะนะ :

• mjb ของ Martin J. Bligh (Scalability)
• wli ของ William Lee Irwin (VM)
• lsm ของ Chris Wright (Linux Security Modules)
• osdl ของ OSDL (database/enterprise-level hacks)
• dj ของ Dave Jones (I/O AGP)
• rmap Rik van Riel (reverse mapping vm)

me:

[kitt@peorth web]$ uname -a
Linux peorth.kitty.in.th 2.6.8.1-ck4 #4
Tue Aug 24 21:30:27 ICT 2004 i686 i686 i386 GNU/Linux

mm4 patch สำหรับ 2.6.8.1 รีลีสแล้ว เร็วดังคาด .. แพตช์ตัวนี้มี experimental code ชุดใหม่เข้ามา ยังไม่ได้ทดสอบในวงกว้าง ใครอยากทดสอบหรือชอบเสี่ยงก็ ดาวน์โหลด ไปใช้ได้

ck4 patch ของ Con Kolivas รีลีสแล้วเหมือนกัน .. แพตช์/จูนสำหรับเดสก์ท็อปเช่นเคย มีแพตช์ workaround kernel กับ cdrecord ไว้แล้วด้วย ใครใช้งาน CD/DVD Writer เอาแพตช์นี้ไปใช้ก่อนระหว่างรอแก้ไขในเคอร์เนลจริงๆ อีกที ในแพตช์เซ็ตมี Reiser4FS ด้วย ว่ากันว่าเร็วโคตรๆ ..

CK แนะนำว่า เคอร์เนล 2.6 ไม่จำเป็นต้องใช้ kernel preemptible ก็ได้ จะ enable หรือ disable ก็ไม่รู้สึกอะไร เพราะ latency ของ 2.6 ถึงไม่มี preempt ก็ต่ำ(กว่า 2.4)อยู่แล้ว การ enable kernel preemptible อาจจะทำให้โปรแกรมบางโปรแกรมทำงานเพี้ยนอีกด้วย ผมก็เจอบ้างเหมือนกัน เช่น NVIDIA ถ้าภาระงานหนักๆ โมดูลจะทำงานอืดอย่างเห็นได้ชัด ALSA เองก็จะกระตุกๆๆ เท่าที่มีการรายงานบางจังหวะแย่ถึงขนาด latency เกิน 50 msec ก็มี ..

เพื่อแก้ปัญหานี้ Ingo Molnar กับ Arjan van de Ven (@ Red Hat) เสนอโมเดลและแพตช์ชื่อ “Voluntary Kernel Preemption” มาเสริมการทำงานของเคอร์เนล 2.6 .. วิธีการคือดึงเอาจังหวะ might_sleep() ในเคอร์เนลมาใช้ + แก้ไขโค้ด จัด schedule ใหม่ (ผมเดาว่า การใช้ might_sleep() คงเป็นที่มาของคำว่า voluntary – เพราะจุดที่เรียก might_sleep() แปลว่ามันอาสาที่จะ sleep แล้ว) .. การทดสอบ voluntary kernel preemption โดยตัว Ingo เองได้ latency ออกมาไม่ถึง 1 ms แม้จะอัดภาระงานเข้าไปเต็มๆ แล้วก็ตาม .. ตัวเลข 1 msec นี่ถือว่าเทียบเท่าหรืออาจจะดีกว่าเคอร์เนล 2.4 + low latency patch ของ Andrew Morton ที่กลุ่ม Linux Audio นิยมใช้กันเสียอีก :)

อย่างไรก็ตามแฮ็กเกอร์บางคน (i.e., Christoph Hellwig, Andrea Arcangeli) ก็ไม่ค่อยจะเห็นด้วยกับการใช้จังหวะ might_sleep() มา reschedule / preempt เพราะโดยหลักการแล้ว might_sleep() มีนิยามในการทำงานของมันเอง และถ้าจะทำอะไรกับ scheduling ก็มี cond_resched() API ให้ใช้อยู่แล้ว .. Ingo ก็ยอมรับว่ามันมีผลดีผลเสียที่ต้อง tradeoff กันอยู่ ที่เสนอให้ใช้ might_sleep() ก็เพราะมันได้ผลที่ดี ประหยัดกว่า และปลอดภัยกว่า .. จะใช้หรือไม่ก็ตัดสินใจเอาเอง โดยสรุป voluntary kernel preepmtion จะเหมาะกับเครื่องที่ต้องการ latency ต่ำๆ ต้องการการตอบสนองที่ดี เช่น digital audio/video workstation แต่อาจจะไม่เหมาะกับเซิร์ฟเวอร์ที่ต้องการทรูพุตสูงๆ .. voluntary kernel preemption สามารถ enable/disable ขณะที่เครื่องทำงานอยู่ได้ตลอดเวลาผ่านทาง /proc ..

ระหว่างนี้ Ingo กำลังทำแพตช์อีกตัวนึงเพื่อปรับปรุง kernel preemption โดยแพตช์ที่จะออกตามมานี้จะจูน preemption ในระดับ per-task ได้เลย :)