หนึ่งในนักพัฒนาซอฟต์แวร์จาก Google ในรายชื่อผู้รับจดหมาย LLVM เกี่ยวกับการพัฒนาไลบรารี C มาตรฐานหลายแพลตฟอร์ม (Libc) ซึ่งเป็นส่วนหนึ่งของโครงการ LLVM ด้วยเหตุผลหลายประการ Google ไม่พอใจกับ libc ในปัจจุบัน (glibc, musl) และบริษัทกำลังดำเนินการพัฒนาการใช้งานใหม่ ซึ่งได้รับการเสนอให้พัฒนาโดยเป็นส่วนหนึ่งของ LLVM
เมื่อเร็วๆ นี้ การพัฒนา LLVM ได้ถูกนำมาใช้เป็นพื้นฐานสำหรับการสร้างเครื่องมือประกอบของ Google แนวคิดหลักคือถ้า Google ได้เริ่มพัฒนา libc แล้ว ทำไมไม่พัฒนาระบบทันทีโดยเป็นส่วนหนึ่งของ LLVM ซึ่งมีไลบรารีมาตรฐานสำหรับ C++ (Libc++) อยู่แล้ว แต่ไม่มีไลบรารีมาตรฐานที่คล้ายกันสำหรับ C (libc).
การพัฒนามีการวางแผนให้ดำเนินการเป็นขั้นตอน โดยค่อยๆ เพิ่มฟังก์ชันการทำงาน ตัวเลือกแรกเสนอให้ออกแบบเป็นเลเยอร์ระหว่างแอปพลิเคชันและระบบ Libc ซึ่งจะมีการยืมคุณลักษณะที่ยังไม่ได้นำไปใช้ หลังจากถึงระดับการทำงานถึงระดับหนึ่งแล้ว Libc ใหม่จะสามารถนำมาใช้แทนระบบ Libc ได้อย่างสมบูรณ์ เราวางแผนที่จะเริ่มต้นด้วยการรองรับสถาปัตยกรรม x86-64, Linux และการเชื่อมโยงแบบคงที่ (การโหลดแบบไดนามิก การเชื่อมโยง และสถาปัตยกรรมเพิ่มเติมจะถูกนำไปใช้ในขั้นที่สอง)
โครงการยังอยู่ในช่วงเริ่มต้นของการพัฒนา แต่เป้าหมายพื้นฐานได้ถูกกำหนดไว้แล้ว:
- ความเป็นโมดูลและการพัฒนาตามปรัชญาของการส่งมอบห้องสมุดแบบละเอียดมากกว่าชุดเสาหิน
- รองรับการเชื่อมโยงแบบคงที่ในโหมด (ปฏิบัติการที่ไม่ขึ้นกับตำแหน่ง) และไม่มี PIE จัดเตรียม CRT (รันไทม์ C) และตัวโหลด PIE สำหรับโปรแกรมปฏิบัติการที่เชื่อมโยงแบบคงที่
- รองรับฟังก์ชันไลบรารี C มาตรฐานส่วนใหญ่ พร้อมด้วยการเพิ่ม POSIX และส่วนขยายเฉพาะระบบบางอย่างที่จำเป็นสำหรับแอปพลิเคชันที่มีอยู่
- โปรดใช้ความระมัดระวังกับส่วนขยายเฉพาะของผู้จำหน่าย และเพิ่มเมื่อจำเป็นเท่านั้น เกี่ยวกับการสนับสนุนส่วนขยายของบุคคลที่สาม ขอเสนอให้ใช้แนวทางของโครงการ Clang และ libc++
- การใช้แนวทางปฏิบัติที่ดีที่สุดในการพัฒนาโดยใช้ชุดเครื่องมือ LLVM เช่น การใช้น้ำยาฆ่าเชื้อและการทดสอบฟัซตั้งแต่เริ่มต้น
หนึ่งในนักพัฒนา LLVM ที่ใช้งานอยู่ ชัดเจนว่าเป็นเรื่องสมเหตุสมผลที่จะจัดส่ง libc โดยเป็นส่วนหนึ่งของชุดเครื่องมือ LLVM แต่โดยปกติแล้ว เมื่อมีความจำเป็นเกิดขึ้น พวกเขาจะใช้ไลบรารี musl ซึ่งได้รับการเขียนมาอย่างดี รองรับสถาปัตยกรรมต่างๆ และจัดเตรียมฟังก์ชันการทำงานที่จำเป็น รวมถึงการรองรับไดนามิก การเชื่อมโยง อาจมีเหตุผลที่จะฝัง musl ลงใน LLVM และพัฒนาเป็นทางแยกที่ซิงโครไนซ์กับโครงการหลัก
ความคิดเห็นของคุณด้วย ผู้เขียนโครงการ Musl ซึ่งพยายามโต้แย้งว่าทำไมข้อเสนอของ Google และการรวม Libc ในการแจกจ่าย LLVM จึงเป็นแนวคิดที่แย่มาก:
- การพัฒนาและรักษา Libc ที่ถูกต้อง เข้ากันได้ และมีคุณภาพสูงนั้นเป็นงานที่ยากมาก ปัญหาไม่ได้อยู่ที่จำนวนโค้ด แต่ในการตรวจสอบพฤติกรรมที่ถูกต้องและความยากลำบากในการใช้งานอินเทอร์เฟซ โดยคำนึงถึงเลเยอร์ขนาดใหญ่ของแอปพลิเคชันที่เคยเขียนด้วย C/C++ รวมถึงแอปพลิเคชันในภาษาอื่น ๆ ซึ่งรันไทม์ที่ใช้ โดย Libc. แนวทางแบบตรงหน้าโดยไม่คำนึงถึงความแตกต่างจะนำไปสู่ความจริงที่ว่าโปรแกรมที่มีอยู่จำนวนมากจะไม่สามารถทำงานร่วมกับ Libc ได้ แต่โครงการดังกล่าวจะไม่เป็นที่สนใจของผู้บริโภค
- การพัฒนาองค์กรสามารถทำลาย Libc ได้ แต่ผลักดันให้มีการใช้งานอย่างแพร่หลาย ส่งผลให้จำเป็นต้องเพิ่มการแฮ็กเพื่อให้มั่นใจถึงความเข้ากันได้ในแอปพลิเคชัน การพัฒนาภายใต้การอุปถัมภ์ของโครงการโอเพ่นซอร์สขององค์กรจะดึงความสนใจไปที่ความต้องการและวิธีแก้ปัญหาของบริษัท ไปสู่ความเสียหายต่อผลประโยชน์ของชุมชน ตัวอย่างเช่น หากคุณระบุปัญหาที่เกิดจากจุดบกพร่องในโปรแกรมอื่น ในการพัฒนาแบบควบคุม จะง่ายกว่าที่จะตรวจสอบให้แน่ใจว่า Libc เข้ากันได้กับจุดบกพร่องนี้มากกว่าการแก้ไขจุดบกพร่องเอง Apple ใช้ BSD libc fork เพื่อจุดประสงค์เหล่านี้ และ Google ใช้ musl fork ใน Fuchsia ประสบการณ์ของนักพัฒนา Musl คือเขาได้รับการติดต่อจากทนายความเป็นหลักเพื่อชี้แจงประเด็นเรื่องลิขสิทธิ์ แต่ไม่เคยได้รับการติดต่อเพื่อชี้แจงรายละเอียดทางเทคนิคก่อนที่จะทำการเปลี่ยนแปลงสาขาของเขาอย่างไร้ประโยชน์และก่อกวน
- การไม่มีวัฒนธรรมเชิงเดี่ยวในการพัฒนา libc และการมุ่งเน้นไปที่มาตรฐานที่ขับเคลื่อนด้วยฉันทามติมากกว่าการควบคุมแต่เพียงผู้เดียว ซึ่งเป็นแรงจูงใจให้นักพัฒนาแอปพลิเคชันใช้มาตรฐานแทนที่จะเชื่อมโยงกับการใช้งานที่เฉพาะเจาะจง นั่นคือเหตุผลที่ผู้เขียน musl ต่อต้านการรวมไลบรารีของเขาใน LLVM เช่นเดียวกับการพัฒนา libc ภายใน LLVM เนื่องจากในกรณีนี้ ลักษณะอิสระของ libc จะหายไป และการนำไปใช้งานบางอย่างกลายเป็นโซลูชันชั้นหนึ่งสำหรับ LLVM และอื่นๆ ทั้งหมดกลายเป็นโซลูชันระดับสอง
ที่มา: opennet.ru