เคอร์เนล Linux ทดสอบอย่างไร?

นักพัฒนาเคอร์เนล Linux จะทดสอบรหัสของพวกเขาแบบโลคัลและหลังจากที่พวกเขายอมรับแล้ว? พวกเขาใช้การทดสอบหน่วยการสร้างอัตโนมัติหรือไม่? แผนการทดสอบ?

เคอร์เนล linux ให้ความสำคัญอย่างมากกับการทดสอบชุมชน

โดยทั่วไปนักพัฒนาซอฟต์แวร์ใด ๆ จะทดสอบโค้ดของตัวเองก่อนที่จะส่งและบ่อยครั้งที่พวกเขาจะใช้เคอร์เนลรุ่นพัฒนาจาก Linus หรือหนึ่งในแผนผังที่ไม่เสถียร / พัฒนาอื่น ๆ สำหรับโครงการที่เกี่ยวข้องกับงานของพวกเขา ซึ่งหมายความว่าพวกเขามักจะทดสอบการเปลี่ยนแปลงและการเปลี่ยนแปลงของผู้อื่น

มีแนวโน้มไม่มากนักในแผนการทดสอบที่เป็นทางการ แต่อาจมีการขอการทดสอบเพิ่มเติมก่อนที่จะรวมคุณสมบัติต่าง ๆ เข้ากับต้นน้ำ

ดังที่ Dean ชี้ให้เห็นนอกจากนี้ยังมีการทดสอบอัตโนมัติโครงการทดสอบ linuxและเคอร์เนล autotest ( ภาพรวมที่ดี )

นักพัฒนามักจะเขียนการทดสอบอัตโนมัติที่กำหนดเป้าหมายเพื่อทดสอบการเปลี่ยนแปลงของพวกเขา แต่ฉันไม่แน่ใจว่ามีกลไก (มักใช้) เพื่อรวบรวมการทดสอบเฉพาะกิจเหล่านี้จากส่วนกลาง

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

โดยปกติแล้วเคอร์เนลและชิ้นส่วนของมันจะถูกทดสอบก่อนการเปิดตัว แต่การทดสอบเหล่านี้ครอบคลุมเฉพาะฟังก์ชันการทำงานพื้นฐาน มีระบบทดสอบบางตัวที่ใช้ทดสอบ Linux Kernel:

โครงการทดสอบ Linux (LTP)มอบชุดทดสอบให้กับชุมชนโอเพนซอร์สที่ตรวจสอบความน่าเชื่อถือและความเสถียรของ Linux ชุดทดสอบ LTP มีชุดเครื่องมือสำหรับการทดสอบเคอร์เนล Linux และคุณสมบัติที่เกี่ยวข้อง https://github.com/linux-test-project/ltp

Autotest - เฟรมเวิร์กสำหรับการทดสอบอัตโนมัติเต็มรูปแบบ มันถูกออกแบบมาเพื่อทดสอบเคอร์เนลของ Linux เป็นหลักแม้ว่ามันจะมีประโยชน์สำหรับวัตถุประสงค์อื่น ๆ เช่นการทดสอบฮาร์ดแวร์ใหม่การจำลองเสมือนและการทดสอบโปรแกรมพื้นที่ผู้ใช้ทั่วไปอื่น ๆ ภายใต้แพลตฟอร์ม Linux มันเป็นโครงการโอเพนซอร์ซภายใต้ GPL และใช้และพัฒนาโดยหลายองค์กรรวมถึง Google, IBM, Red Hat และอื่น ๆ อีกมากมาย http://autotest.github.io/

นอกจากนี้ยังมีระบบการรับรองที่พัฒนาโดย บริษัท ผู้จัดจำหน่าย GNU / Linux รายใหญ่บางราย ระบบเหล่านี้มักจะตรวจสอบการแจกแจง GNU / Linux ที่สมบูรณ์เพื่อความเข้ากันได้กับฮาร์ดแวร์ มีระบบการรับรองการพัฒนาโดยมีโนเวลล์, Red Hat, Oracle, ยอมรับ, Google

นอกจากนี้ยังมีระบบสำหรับการวิเคราะห์แบบไดนามิกของเคอร์เนล Linux:

Kmemleakเป็นตัวตรวจจับการรั่วไหลของหน่วยความจำที่รวมอยู่ในเคอร์เนล Linux มันมีวิธีการในการตรวจสอบการรั่วไหลของหน่วยความจำเคอร์เนลที่เป็นไปได้ในลักษณะคล้ายกับการติดตามขยะที่มีความแตกต่างที่วัตถุเด็กกำพร้าไม่ได้เป็นอิสระ แต่รายงานเพียงผ่าน / sys / kernel / debug / kmemleak

Kmemcheckดักทุกการอ่านและเขียนไปยังหน่วยความจำที่จัดสรรแบบไดนามิก (เช่นกับ kmalloc ()) หากอ่านที่อยู่หน่วยความจำที่ไม่ได้ถูกเขียนไปก่อนหน้านี้ข้อความจะถูกพิมพ์ไปยังบันทึกเคอร์เนล ยังเป็นส่วนหนึ่งของเคอร์เนล Linux

Fault Injection Framework (รวมอยู่ในเคอร์เนล Linux) อนุญาตให้ใส่ข้อผิดพลาดและข้อยกเว้นลงในตรรกะของแอปพลิเคชันเพื่อให้ได้ความครอบคลุมที่สูงขึ้นและการยอมรับข้อผิดพลาดของระบบ

นักพัฒนาเคอร์เนล Linux จะทดสอบรหัสของพวกเขาแบบโลคัลและหลังจากที่พวกเขายอมรับแล้ว?

พวกเขาใช้การทดสอบหน่วยการสร้างอัตโนมัติหรือไม่?

ในความหมายของคำคลาสสิกไม่ใช่

เช่น. Ingo Molnar กำลังเรียกใช้งานเวิร์กโหลดต่อไปนี้: 1. สร้างเคอร์เนลใหม่พร้อมชุดตัวเลือกการกำหนดค่าแบบสุ่ม 2. บูตเข้าไป 3. ไปที่ 1

ทุกบิลด์ล้มเหลว, บูตล้มเหลว, BUG หรือคำเตือนรันไทม์จะได้รับการจัดการ 24/7 ทวีคูณด้วยกล่องหลายกล่องและสามารถค้นพบปัญหาได้ค่อนข้างมาก

แผนการทดสอบ?

เลขที่

อาจมีความเข้าใจผิดว่ามีศูนย์ทดสอบกลางไม่มีเลย ทุกคนทำในสิ่งที่เขาต้องการ

เครื่องมือในต้นไม้

วิธีที่ดีในการค้นหาเครื่องมือทดสอบในเคอร์เนลคือ:

• make help และอ่านเป้าหมายทั้งหมด
• ดูภายใต้เครื่องมือ / การทดสอบ

ใน v4.0 สิ่งนี้ทำให้ฉัน:

• kselftestภายใต้เครื่องมือ / ทดสอบ / selftests make kselftestทำงานด้วย ต้องรันเคอร์เนลที่สร้างไว้แล้ว ดูเพิ่มเติมที่: Documentation / kselftest.txt , https://kselftest.wiki.kernel.org/

• ktestภายใต้เครื่องมือ / ทดสอบ / ktest ดูเพิ่มเติมที่: http://elinux.org/Ktest , http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest

• ส่วนวิเคราะห์แบบคงที่ของmake helpซึ่งมีเป้าหมายเช่น:

  • checkstack: Perl: checkstack.pl ใน linux source ทำอะไรได้บ้าง?
  • coccicheckสำหรับ Coccinelle (กล่าวโดย askb )

เคอร์เนล CI

https://kernelci.org/เป็นโครงการที่มีจุดประสงค์เพื่อให้การทดสอบเคอร์เนลเป็นไปอย่างอัตโนมัติ

ดูเหมือนว่าจะสร้างและทดสอบบูตเท่านั้น (สิ่งที่ต้องทำเพื่อทดสอบโดยอัตโนมัติว่าบูตทำงานได้หรือไม่แหล่งที่มาควรอยู่ที่https://github.com/kernelci/ )

Linaroดูเหมือนจะเป็นผู้ดูแลหลักของโครงการโดยได้รับการสนับสนุนจาก บริษัท ใหญ่ ๆ หลายแห่ง: https://kernelci.org/sponsors/

Linaro Lava

http://www.linaro.org/initiatives/lava/ดูเหมือนว่าระบบ CI โดยมุ่งเน้นที่การพัฒนาบอร์ดพัฒนาและลินุกซ์เคอร์เนล

ARM LISA

https://github.com/ARM-software/lisa

ไม่แน่ใจว่ามันทำอะไรในรายละเอียด แต่โดย ARM และ Apache Licensed จึงมีแนวโน้มที่จะดูดี

ตัวอย่าง: https://www.youtube.com/watch?v=yXZzzUEngiU

ขั้นตอนการดีบั๊ก

ไม่ใช่การทดสอบหน่วย แต่อาจช่วยได้เมื่อการทดสอบของคุณเริ่มล้มเหลว:

• QEMU + GDB: https://stackoverflow.com/a/42316607/895245
• KGDB: https://stackoverflow.com/a/44226360/895245

การตั้งค่า QEMU + Buildroot + Python ของฉันเอง

ฉันเริ่มตั้งค่าที่เน้นความสะดวกในการพัฒนา แต่ท้ายที่สุดฉันก็เพิ่มความสามารถในการทดสอบอย่างง่าย ๆ เช่นกัน: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/8217e5508782827320209644dcbaf9a6b3141724#test-this -repo

ฉันไม่ได้วิเคราะห์การตั้งค่าอื่น ๆ ทั้งหมดอย่างละเอียดและพวกเขาก็น่าจะทำได้มากกว่าของฉันอย่างไรก็ตามฉันเชื่อว่าการตั้งค่าของฉันนั้นง่ายมากที่จะเริ่มต้นใช้งานได้อย่างรวดเร็วเพราะมีเอกสารและระบบอัตโนมัติจำนวนมาก

การทดสอบเคอร์เนลไม่ใช่เรื่องง่าย นักพัฒนา Linux ส่วนใหญ่ทำการทดสอบด้วยตัวเองเหมือนกับที่ adobriyan พูดถึง

อย่างไรก็ตามมีบางสิ่งที่ช่วยในการดีบักเคอร์เนล Linux:

• kexec:การเรียกระบบที่ช่วยให้คุณใส่เคอร์เนลอื่นลงในหน่วยความจำและรีบูตโดยไม่ต้องกลับไปที่ BIOS และหากล้มเหลวให้รีบูต
• dmesg:สถานที่ที่แน่นอนในการค้นหาข้อมูลเกี่ยวกับสิ่งที่เกิดขึ้นในระหว่างการบูตเคอร์เนลและไม่ว่าจะทำงาน / ไม่ทำงาน
• เครื่องมือเคอร์เนล:นอกเหนือไปจาก printk (และตัวเลือกที่เรียกว่า 'CONFIG_PRINTK_TIME' ซึ่งช่วยให้คุณเห็น (ความแม่นยำระดับไมโครวินาที) เมื่อเคอร์เนลเอาต์พุตคืออะไร) การกำหนดค่าเคอร์เนลช่วยให้คุณสามารถเปิดใช้เครื่องมือตรวจสอบจำนวนมากที่เปิดใช้งาน กำลังเกิดขึ้น

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

แก้ไข: ต่อไปนี้เป็นวิดีโอที่ดีที่แสดงรายละเอียดกระบวนการที่แพตช์ดำเนินการก่อนที่จะรวมเข้ากับเคอร์เนล

นอกเหนือจากจุดด้านบน / ด้านล่างซึ่งเน้นเพิ่มเติมเกี่ยวกับการทดสอบการทำงานการทดสอบการรับรองฮาร์ดแวร์และการทดสอบประสิทธิภาพของเคอร์เนล Linux

การทดสอบจำนวนมากเกิดขึ้นจริง ๆ แล้วจริงๆแล้วสคริปต์เครื่องมือวิเคราะห์โค้ดแบบสแตติกการตรวจทานโค้ด ฯลฯ ซึ่งมีประสิทธิภาพมากในการดักจับข้อบกพร่องซึ่งอาจทำให้บางอย่างผิดปกติในแอปพลิเคชัน

Sparse - เครื่องมือโอเพนซอร์ซที่ออกแบบมาเพื่อค้นหาความผิดพลาดในเคอร์เนล Linux

Coccinelleเป็นอีกโปรแกรมหนึ่งที่จับคู่และแปลงเอ็นจิ้นซึ่งให้บริการภาษา SmPL (Semantic Patch Language) สำหรับการระบุการจับคู่และการแปลงที่ต้องการในรหัส C

checkpatch.pl และสคริปต์อื่น ๆ - พบปัญหาสไตล์การเขียนรหัสในไฟล์เอกสาร / CodingStyle ในแผนผังต้นฉบับของเคอร์เนล สิ่งสำคัญที่ต้องจำไว้เมื่ออ่านไม่ใช่ว่าสไตล์นี้ดีกว่าสไตล์อื่นใด สิ่งนี้ช่วยให้นักพัฒนาสามารถค้นหาและแก้ไขปัญหาลักษณะการเขียนโค้ดได้อย่างง่ายดายสคริปต์สคริปต์ / checkpatch.pl ในแผนผังต้นกำเนิดเคอร์เนลได้รับการพัฒนา สคริปต์นี้สามารถชี้ปัญหาได้อย่างง่ายดายและนักพัฒนาควรดำเนินการกับการเปลี่ยนแปลงเสมอแทนที่จะให้ผู้ตรวจสอบเสียเวลาโดยระบุปัญหาในภายหลัง

ฉันคิดว่าพวกเขาใช้การจำลองเสมือนเพื่อทำการทดสอบอย่างรวดเร็วเช่น QEMU, VirtualBox หรือ Xen และสคริปต์บางอย่างเพื่อดำเนินการกำหนดค่าและทดสอบอัตโนมัติ

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

นอกจากนี้ยังมี:

MMTestsซึ่งเป็นชุดของมาตรฐานและสคริปต์เพื่อวิเคราะห์ผลลัพธ์

https://github.com/gormanm/mmtests

Trinityซึ่งเป็นระบบทดสอบระบบ fuzz ของ call

http://codemonkey.org.uk/projects/trinity/

นอกจากนี้หน้าLTPที่ sourceforge ค่อนข้างล้าสมัยและโครงการได้ย้ายไปที่ GitHub https://github.com/linux-test-project/ltp

เท่าที่ฉันรู้มีเครื่องมือตรวจสอบประสิทธิภาพการถดถอยโดยอัตโนมัติ (ชื่อ lkp / 0 วัน) ที่ใช้งาน / ระดมทุนโดย Intel จะทดสอบแต่ละแพทช์ที่ถูกต้องที่ส่งไปยังรายชื่อผู้รับจดหมายและตรวจสอบคะแนนที่เปลี่ยนจาก microbenchmarks ต่างๆ , fio, unixbench, netperf และอื่น ๆ เมื่อมีการถดถอย / ปรับปรุงประสิทธิภาพรายงานที่เกี่ยวข้องจะถูกส่งโดยตรงไปยังผู้เขียนโปรแกรมแก้ไขและผู้ดูแลระบบที่เกี่ยวข้องกับ Cc

LTP และ Memtests เป็นเครื่องมือที่ต้องการโดยทั่วไป

adobriyan กล่าวถึงการวนรอบของ Ingo ของการทดสอบการตั้งค่าแบบสุ่ม นั่นคือตอนนี้สวยมากครอบคลุมโดย bot ทดสอบ 0 วัน (aka kbuild ทดสอบ bot) บทความดีๆเกี่ยวกับโครงสร้างพื้นฐานถูกนำเสนอที่นี่: การทดสอบ Kernel Build / boot

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

ฉันได้ทำการรวบรวมเคอร์เนล linux และทำการแก้ไขบางอย่างสำหรับ android (Marshmallow และ Nougat) ซึ่งฉันใช้ linux version 3 ฉันข้ามการคอมไพล์ในระบบ linux ตรวจแก้ข้อผิดพลาดด้วยตนเองจากนั้นเรียกใช้ไฟล์อิมเมจสำหรับบูตใน Android และตรวจสอบว่า มันเป็นรูวนหรือไม่ ถ้ามันทำงานได้สมบูรณ์ก็หมายความว่ามันถูกรวบรวมอย่างสมบูรณ์แบบตามข้อกำหนดของระบบ
สำหรับการรวบรวมเคอร์เนล MotoG

หมายเหตุ: -เคอร์เนล Linux จะเปลี่ยนไปตามข้อกำหนดซึ่งขึ้นอยู่กับฮาร์ดแวร์ของระบบ

หลังจากผู้ดูแลระบบส่งไฟล์แพทช์ของพวกเขา & หลังจากทำการร้องขอลินุกซ์ gatekeepers กำลังตรวจสอบแพทช์โดยการรวมและตรวจสอบเมื่อมันประสบความสำเร็จพวกเขาจะรวมแพทช์เข้ากับสาขาที่เกี่ยวข้องและปล่อยเวอร์ชั่นใหม่ โครงการทดสอบลินุกซ์ ( https://github.com/linux-test-project/ltp ) เป็นแหล่งที่มาหลักซึ่งให้สถานการณ์การทดสอบ (กรณีทดสอบ) เพื่อเรียกใช้กับเคอร์เนลหลังจากใช้แพทช์ อาจใช้เวลาประมาณ 2 ~ 4 ชั่วโมงและขึ้นอยู่กับ โปรดทราบเกี่ยวกับระบบไฟล์ของเคอร์เนลที่เลือกจะทำการทดสอบ ตัวอย่าง: Ext4 สร้างผลลัพธ์ที่แตกต่างกับ EXT3 และอื่น ๆ

ขั้นตอนการทดสอบเคอร์เนล

1. รับแหล่งเคอร์เนลล่าสุดจากพื้นที่เก็บข้อมูล ( https://www.kernel.org/หรือ Github.com)
2. ใช้ไฟล์ปะ (ใช้เครื่องมือดิฟ)
3. สร้างเคอร์เนลใหม่
4. ทดสอบกับขั้นตอนการทดสอบใน LTP ( https://github.com/linux-test-project/ltp )