लिनक्स कर्नेल का परीक्षण कैसे किया जाता है?


258

लिनक्स कर्नेल डेवलपर्स अपने कोड का स्थानीय स्तर पर परीक्षण कैसे करते हैं और वे इसे करने के बाद? क्या वे किसी प्रकार के यूनिट परीक्षण का उपयोग करते हैं, स्वचालन का निर्माण करते हैं? परीक्षण की योजना?


16
youtube.com/watch?v=L2SED6SHRw , कहीं, मुझे ठीक से याद नहीं है, लेकिन मुझे लगता है कि क्यूए सेक्शन में इस बारे में बात की जा रही है।
एंडर्स

6
एंडर्स का लिंक बहुत अच्छा है - शीर्ष कर्नेल डेवलपर्स, ग्रेग क्रोहा हार्टमैन द्वारा एक Google टेक टॉक। वह कर्नेल डेवलपर @adobriyan द्वारा दिए गए उत्तर को मान्य करता है। ग्रेग कर्नेल के बारे में मजेदार बात नोट करता है - इसे चलाने के बिना परीक्षण करने का कोई अच्छा तरीका नहीं है - यूनिट परीक्षण करना कठिन है - कई क्रमपरिवर्तन। "हम परीक्षण करने के लिए विकास समुदाय पर भरोसा करते हैं। हम उतने ही कार्यात्मक परीक्षण चाहते हैं जितना हम प्राप्त कर सकते हैं, और प्रदर्शन परीक्षण भी।" परीक्षण चर्चा के लिए सीधे एक लिंक youtube.com/… है
nealmcb

VMs की लोकप्रियता के साथ, यह संभव नहीं होगा कि यह विन्यास क्रमपरिवर्तन के एक समूह के साथ कर्नेल के निर्माण और उन पर बूट करने की कोशिश कर रहा हो? यह किसी भी तरह से एक "इकाई" परीक्षण नहीं होगा, लेकिन यह बग को पकड़ सकता है।
डैनियल कपलान

@DanielKaplan: यदि आप मानते हैं कि लगभग 1000 मदरबोर्ड हैं, जिनमें से प्रत्येक में 10 सीपीयू, 1000 पीसीआई उपकरणों में से 3, 1000 यूएसबी उपकरणों के साथ 3 हैं; और यह कि कर्नेल में 1000 अलग-अलग संभवत: समय विकल्प संकलित हैं; फिर आप 1000 * 10 * 1000 * 999 * 9981000 * 999 * 998 * 1000 संभावित क्रमपरिवर्तन को देख रहे हैं। यदि आप प्रत्येक क्रमपरिवर्तन के लिए 8 घंटे का एक अच्छा परीक्षण करते हैं और एक ही समय में समानांतर में 400 वीएम को चलाने के लिए 100 सर्वरों का एक पूल है; तब तक आपको 1 मिलियन मिल चुका है, इसका परीक्षण करने पर परिणाम सभी अप्रचलित हो जाएंगे क्योंकि किसी ने कोड बदल दिया है और आपको फिर से शुरू करना होगा।
ब्रेंडन

जवाबों:


76

लिनक्स कर्नेल का सामुदायिक परीक्षण पर भारी जोर है।

आमतौर पर कोई भी डेवलपर सबमिट करने से पहले अपने स्वयं के कोड का परीक्षण करेगा, और अक्सर वे लाइनस से कर्नेल के विकास संस्करण का उपयोग कर रहे होंगे, या अपने काम के लिए प्रासंगिक परियोजना के लिए अन्य अस्थिर / विकास पेड़ों में से एक। इसका मतलब है कि वे अक्सर अपने परिवर्तनों और अन्य लोगों के परिवर्तनों दोनों का परीक्षण कर रहे हैं।

औपचारिक परीक्षण योजनाओं के तरीके में बहुत कुछ नहीं है, लेकिन सुविधाओं को अपस्ट्रीम पेड़ों में विलय करने से पहले अतिरिक्त परीक्षण के लिए कहा जा सकता है।

जैसा कि डीन ने बताया, कुछ स्वचालित परीक्षण, लिनक्स परीक्षण परियोजना और कर्नेल ऑटोटेस्ट ( अच्छा अवलोकन ) भी है।

डेवलपर्स अक्सर अपने परिवर्तन का परीक्षण करने के लिए लक्षित स्वचालित परीक्षण भी लिखेंगे, लेकिन मुझे यकीन नहीं है कि इन एडहॉक परीक्षणों को केंद्रीय रूप से इकट्ठा करने के लिए (अक्सर उपयोग किया जाता है) तंत्र है।

यह बहुत कुछ निर्भर करता है कि कर्नेल के किस क्षेत्र को निश्चित रूप से बदला जा रहा है - एक नए नेटवर्क ड्राइवर के लिए आप जो परीक्षण करेंगे वह मुख्य निर्धारण एल्गोरिथ्म को बदलने के दौरान आपके द्वारा किए जाने वाले परीक्षण के लिए काफी अलग है।


8
+1, आधी लड़ाई बस कुछ ऐसा नहीं तोड़ रही है जो ड्राइवर पर निर्भर करते हैं, इसलिए बीकेएल की दृढ़ता पिछले कुछ वर्षों में बनी हुई है। दूसरी बात पर विचार करना कई अलग-अलग आर्किटेक्चर पर कई उप प्रणालियों का परीक्षण कर रहा है, जो केवल व्यावहारिक रूप से संभव है, जिस तरह के सामुदायिक दुर्व्यवहार, गलत परीक्षण के साथ, लिनक्स प्राप्त करता है।
टिम पोस्ट

66

स्वाभाविक रूप से, कर्नेल स्वयं और उसके भागों को रिलीज से पहले परीक्षण किया जाता है, लेकिन ये परीक्षण केवल मूल कार्यक्षमता को कवर करते हैं। कुछ परीक्षण प्रणालियाँ हैं जो लिनक्स कर्नेल का परीक्षण करती हैं:

लिनक्स टेस्ट प्रोजेक्ट (एलटीपी) ओपन सोर्स समुदाय के लिए टेस्ट सूट वितरित करता है जो लिनक्स की विश्वसनीयता और स्थिरता को मान्य करता है। LTP टेस्ट सूट में लिनक्स कर्नेल और संबंधित सुविधाओं के परीक्षण के लिए उपकरणों का एक संग्रह होता है। https://github.com/linux-test-project/ltp

ऑटोटेस्ट - पूरी तरह से स्वचालित परीक्षण के लिए एक रूपरेखा। यह मुख्य रूप से लिनक्स कर्नेल का परीक्षण करने के लिए डिज़ाइन किया गया है, हालांकि यह कई अन्य प्रयोजनों के लिए उपयोगी है जैसे कि नए हार्डवेयर, वर्चुअलाइजेशन परीक्षण और लिनक्स प्लेटफॉर्म के तहत अन्य सामान्य उपयोगकर्ता अंतरिक्ष कार्यक्रम परीक्षण। यह GPL के तहत एक ओपन-सोर्स प्रोजेक्ट है और इसे Google, IBM, Red Hat और कई अन्य संगठनों द्वारा उपयोग और विकसित किया गया है। http://autotest.github.io/

इसके अलावा कुछ प्रमुख GNU / Linux वितरण कंपनियों द्वारा विकसित प्रमाणन प्रणालियाँ हैं। ये सिस्टम आमतौर पर हार्डवेयर के साथ संगतता के लिए पूर्ण GNU / लिनक्स वितरण की जांच करते हैं। नोवेल, रेड हैट, ओरेकल, कैननिकल, गूगल द्वारा विकसित प्रमाणन प्रणाली हैं ।

लिनक्स कर्नेल के गतिशील विश्लेषण के लिए भी सिस्टम हैं:

Kmemleak लिनक्स कर्नेल में शामिल एक मेमोरी लीक डिटेक्टर है। यह एक प्रकार से संभव कर्नेल मेमोरी लीक का पता लगाने का एक तरीका प्रदान करता है, जिसमें यह पता चलता है कि अनाथ वस्तुओं को मुक्त नहीं किया गया है बल्कि केवल / sys / कर्नेल / डीबग / kmemleak के माध्यम से सूचित किया जाता है।

Kmemcheck प्रत्येक पढ़ने और लिखने के लिए जाल को गतिशील रूप से आवंटित किया गया था (यानी kmalloc () के साथ)। यदि कोई स्मृति पता पढ़ा जाता है जिसे पहले नहीं लिखा गया है, तो एक संदेश कर्नेल लॉग में मुद्रित किया जाता है। इसके अलावा लिनक्स कर्नेल का एक हिस्सा है

दोष इंजेक्शन फ्रेमवर्क (लिनक्स कर्नेल में शामिल) एक उच्च कवरेज और सिस्टम की गलती सहिष्णुता को प्राप्त करने के लिए एक आवेदन के तर्क में त्रुटियों और अपवादों को संक्रमित करने की अनुमति देता है।


62

लिनक्स कर्नेल डेवलपर्स अपने कोड का स्थानीय स्तर पर परीक्षण कैसे करते हैं और वे इसे करने के बाद?

क्या वे किसी प्रकार के यूनिट परीक्षण का उपयोग करते हैं, स्वचालन का निर्माण करते हैं?

शब्दों के क्लासिक अर्थों में, नहीं।

ई। जी। इंगो मोलनार निम्नलिखित कार्यभार चला रहा है: 1. विन्यास विकल्पों के यादृच्छिक सेट के साथ नया कर्नेल बनाएं 2. इसमें बूट करें 3. गोटो 1

हर बिल्ड फेल, बूट फेल, BUG या रनटाइम चेतावनी से निपटा जाता है। 24/7। कई बक्से से गुणा करें, और एक काफी समस्याओं को उजागर कर सकता है।

परीक्षण की योजना?

नहीं।

गलतफहमी हो सकती है कि केंद्रीय परीक्षण सुविधा है, कोई नहीं है। हर कोई वही करता है जो वह चाहता है।


6
जैसे स्थलों के अस्तित्व को देखते हुए यह और इस मैं भी इस सवाल का जवाब की वैधता पर सवाल खड़ा होता है।
डीन हार्डिंग

3
मुझे लगता है कि एडोब्रियन के जवाब का मूल "केंद्रीय परीक्षण सुविधा है, कोई नहीं है।" सही के बारे में है। हालाँकि विभिन्न समूह परीक्षण के विभिन्न स्तरों को करते हैं, ऐसा नहीं है कि कर्नेल पूरी तरह से अप्रयुक्त है।
stsquad

2
मुझे लगता है कि SUSE और RedHat दोनों अपनी खुद की गुठली का परीक्षण करने के अलावा, अक्सर वेनिला का परीक्षण करते हैं। प्रति se कोई केंद्रीय परीक्षण नहीं है, लेकिन फिर भी एक परीक्षण चल रहा है - लिनक्स के प्रमुख उपयोगकर्ताओं द्वारा। अन्यथा टिप्पणी खड़ी है। क्या यह कम व्यंग्यात्मक रूप से लिखा गया था, मैं इसे भी मॉडरेट कर देता।
डमी ००००००१

55
Errr, आप सभी लोगों को पता है कि एलेक्सी Dobriyan करना है एक लिनक्स कर्नेल डेवलपर?
निंजाल

9
एक अन्य कर्नेल डेवलपर के रूप में, मुझे यह कहना चाहिए कि यह सवाल का सबसे ईमानदार जवाब है: कर्नेल को क्लासिक अर्थों में परीक्षण नहीं किया गया है, केवल इसलिए कि यह असंभव है। परीक्षण के लिए उपलब्ध डेवलपर समय की तुलना में कॉन्फ़िगरेशन और हार्डवेयर के संयोजन अधिक हैं। बहुत कम लोगों के पास कुछ उपकरणों का परीक्षण करने के लिए आवश्यक कौशल होते हैं, और कुछ मामलों में बहुत कम लोग वास्तव में कुछ उपकरणों के मालिक होते हैं।
एज़ेकिएल गार्सिया

19

इन-ट्री उपकरण

कर्नेल में परीक्षण उपकरण खोजने का एक अच्छा तरीका है:

V4.0 में, यह मुझे निम्न की ओर ले जाता है:

कर्नेल सीआई

https://kernelci.org/ एक परियोजना है जिसका उद्देश्य कर्नेल परीक्षण को अधिक स्वचालित और दृश्यमान बनाना है।

यह केवल बिल्ड और बूट परीक्षण करने के लिए प्रतीत होता है (TODO स्वचालित रूप से परीक्षण करने के लिए कि बूट काम किया गया स्रोत https://github.com/kernelcii/ पर होना चाहिए )।

कई बड़ी कंपनियों से योगदान के साथ, लिनरो परियोजना का मुख्य अनुरक्षक लगता है: https://kernelci.org/sponsors/

लीनारो लावा

http://www.linaro.org/initiatives/lava/ विकास बोर्ड लाने और लिनक्स कर्नेल पर ध्यान देने के साथ एक CI प्रणाली की तरह दिखता है।

एआरएम लीसा

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

सुनिश्चित नहीं है कि यह विस्तार से क्या करता है, लेकिन यह एआरएम और अपाचे लाइसेंस द्वारा है, इसलिए एक नज़र के लायक है।

डेमो: https://www.youtube.com/watch?v=yXZzzUEngiU

कदम डिबगर्स

वास्तव में इकाई परीक्षण नहीं, लेकिन आपके परीक्षण विफल होने पर एक बार मदद मिल सकती है:

मेरा अपना QEMU + बिल्डरोट + पायथन सेटअप

मैंने विकास में आसानी पर ध्यान केंद्रित करते हुए एक सेटअप भी शुरू किया, लेकिन मैंने कुछ सरल परीक्षण क्षमताओं को भी इसमें शामिल किया: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/8217e5508282828202020204444bcb9a6b3141724#test-thest -repo

मैंने अन्य सभी सेटअपों का बहुत विस्तार से विश्लेषण नहीं किया है, और वे संभवतः मेरी तुलना में बहुत अधिक काम करते हैं, हालांकि मेरा मानना ​​है कि मेरा सेटअप जल्दी से शुरू करना बहुत आसान है क्योंकि इसमें बहुत सारे प्रलेखन और स्वचालन हैं।


13

इसकी कर्नेल टेस्टिंग को स्वचालित करना बहुत आसान नहीं है। अधिकांश लिनक्स डेवलपर्स अपने दम पर परीक्षण करते हैं, जैसा कि एडोब्रियन ने उल्लेख किया है।

हालाँकि, कुछ चीजें हैं जो लिनक्स कर्नेल को डीबग करने में मदद करती हैं:

  • kexec: एक सिस्टम कॉल जो आपको मेमोरी में एक और कर्नेल डालने की अनुमति देता है और BIOS में वापस जाए बिना रिबूट करता है, और यदि यह विफल होता है, तो रिबूट करें।
  • dmesg: निश्चित रूप से कर्नेल बूट के दौरान क्या हुआ और क्या काम करता है / नहीं करता है, इस बारे में जानकारी के लिए जगह है।
  • कर्नेल इंस्ट्रूमेंटेशन: प्रिंटेक के अलावा (और 'CONFIG_PRINTK_TIME' नाम का एक विकल्प जो आपको कर्नेल आउटपुट क्या है, यह देखने की अनुमति देता है (कर्नेल आउटपुट क्या है), कर्नेल कॉन्फ़िगरेशन आपको बहुत सारे ट्रैक्ट को चालू करने की अनुमति देता है जो उन्हें डिबग करने में सक्षम बनाता है। घटित हो रहा है।

फिर, डेवलपर्स आमतौर पर दूसरों को अपने पैच की समीक्षा करते हैं। एक बार जब पैच की स्थानीय रूप से समीक्षा की जाती है और उसे किसी और चीज के साथ हस्तक्षेप नहीं करने के लिए देखा जाता है, और पैच को लिनस से नवीनतम कर्नेल के साथ काम करने के लिए परीक्षण किया जाता है, बिना कुछ टूटे हुए, पैच को ऊपर की ओर धकेल दिया जाता है।

संपादित करें: यहाँ एक अच्छा वीडियो है जिसे पैच में जाने से पहले एक प्रक्रिया के माध्यम से देखा जाता है।


6

ऊपर / नीचे बिंदुओं के अलावा, जो कार्यक्षमता परीक्षण, हार्डवेयर प्रमाणन परीक्षण और लिनक्स कर्नेल के परीक्षण का प्रदर्शन करने पर अधिक जोर देता है।

बहुत सारे परीक्षण वास्तव में स्क्रिप्ट्स, स्टेटिक कोड एनालिसिस टूल्स, कोड रिव्यू आदि के माध्यम से होते हैं, जो बग्स को पकड़ने में बहुत कुशल होते हैं, जो अन्यथा एप्लिकेशन में कुछ तोड़ देगा।

स्पार्स - लिनक्स कर्नेल में दोष खोजने के लिए डिज़ाइन किया गया एक ओपन-सोर्स टूल।

Coccinelle एक अन्य प्रोग्राम है जो मिलान और परिवर्तन इंजन का काम करता है जो सी कोड में वांछित मैचों और परिवर्तनों को निर्दिष्ट करने के लिए भाषा SmPL (शब्दार्थ पैच भाषा) प्रदान करता है।

checkpatch.pl और अन्य स्क्रिप्ट्स - कोडिंग शैली के मुद्दों को कर्नेल ट्री ट्री में फ़ाइल डॉक्यूमेंटेशन / कोडिंग स्टाइल में पाया जा सकता है। इसे पढ़ते समय याद रखने वाली महत्वपूर्ण बात यह नहीं है कि यह शैली किसी भी अन्य शैली की तुलना में बेहतर है, बस यह सुसंगत है। यह डेवलपर्स को आसानी से कोडिंग शैली के मुद्दों को खोजने और ठीक करने में मदद करता है, कर्नेल स्रोत ट्री में स्क्रिप्ट स्क्रिप्ट / चेकपॉच। पीपी विकसित किया गया है। यह स्क्रिप्ट समस्याओं को आसानी से इंगित कर सकती है, और हमेशा एक डेवलपर द्वारा उनके परिवर्तनों पर चलना चाहिए, बजाय एक समीक्षक ने बाद में समस्याओं को इंगित करके अपना समय बर्बाद किया।


3

मुझे लगता है कि वे वर्चुअलाइजेशन का उपयोग त्वरित परीक्षण करने के लिए करते हैं, कुछ QEMU, VirtualBox या Xen, और कुछ स्क्रिप्ट जैसे कॉन्फ़िगरेशन और स्वचालित परीक्षण करने के लिए।

स्वचालित परीक्षण शायद कई यादृच्छिक विन्यास या कुछ विशिष्ट लोगों की कोशिश करके किया जाता है (यदि वे किसी विशिष्ट मुद्दे के साथ काम कर रहे हैं)। लिनक्स में कर्नेल से डीबग डेटा की निगरानी और लॉग करने के लिए बहुत कम-स्तरीय टूल (जैसे dmesg) हैं, इसलिए मुझे लगता है कि इसका भी उपयोग किया जाता है।


आप निश्चित रूप से सही हैं। जब मैंने अपना कर्नेल मॉड्यूल विकास किया, तो मैंने VirtualBox + KGDB पर LINE-BY-LINE पर बहुत निर्भरता से कर्नेल निष्पादन का पता लगाया। जी हाँ, पूरे कर्नेल को लाइन-बाय-लाइन देखने के लिए gdb वास्तव में अच्छा है। वैलेरी ऑरोरा के साथ, प्रसिद्ध कर्नेल डेवलपर, जैसे: youtube.com/watch?v=Tach2CheAc8 । वीडियो के अंदर आप देख सकते हैं कि वह कर्नेल के माध्यम से कदम बढ़ाने के लिए UserModeLinux वर्चुअलाइजेशन का उपयोग कैसे करती है।
पीटर तेह

3

ये भी हैं:

MMTests जो परिणामों का विश्लेषण करने के लिए बेंचमार्क और स्क्रिप्ट का संग्रह है

https://github.com/gormanm/mmtests

ट्रिनिटी जो कि लिनक्स सिस्टम कॉल फज टेस्टर है

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

इसके अलावा सोर्सफोर्ज पर LTP पेज काफी पुराने हैं और यह प्रोजेक्ट GitHub https://github.com/linux-test-project/ltp पर चला गया है


1

जहां तक ​​मुझे पता है, इंटेल द्वारा स्वचालित रूप से प्रदर्शन प्रतिगमन चेक टूल (नाम lkp / 0 दिन) चल रहा है / वित्त पोषण कर रहा है, यह मेलिंग सूची में भेजे गए प्रत्येक वैध पैच का परीक्षण करेगा और हैकबेंक जैसे अलग-अलग माइक्रोबेंचमार्क से बदले गए अंकों की जांच करेगा। , fio, unixbench, netperf इत्यादि, एक बार एक प्रदर्शन प्रतिगमन / सुधार होने के बाद, एक संबंधित रिपोर्ट सीधे पैच लेखक और Cc संबंधित अनुरक्षकों को भेजी जाएगी।



0

adobriyan ने Ingo के लूप का उल्लेख बेतरतीब विन्यास निर्माण परीक्षण में किया। यह बहुत ज्यादा अब 0-दिवसीय टेस्ट बॉट (उर्फ क्रिल्ट टेस्ट बॉट) द्वारा कवर किया गया है। बुनियादी ढांचे के बारे में एक अच्छा लेख यहां प्रस्तुत किया गया है: कर्नेल बिल्ड / बूट परीक्षण

इस सेट-अप के पीछे का विचार डेवलपर्स ASAP को सूचित करना है ताकि वे त्रुटियों को जल्द से जल्द ठीक कर सकें। (इससे पहले कि पैच कुछ मामलों में लिनुस के पेड़ में बन जाए क्योंकि क्रिप्ट इन्फ्रास्ट्रक्चर भी मेंटेनर के सबसिस्टम पेड़ों के खिलाफ परीक्षण करता है)


0

मैंने लिनक्स कर्नेल संकलन किया था और एंड्रॉइड (मार्शमैलो और नूगट) के लिए कुछ संशोधन किए थे, जिसमें मैं लिनक्स संस्करण 3 का उपयोग करता हूं। मैंने इसे लिनक्स सिस्टम में क्रॉस-संकलित किया, त्रुटियों को मैन्युअल रूप से डीबग करें और फिर एंड्रॉइड में अपने बूट फ़ाइल को चलाएं और जांचें कि क्या यह लूप-होल में जा रहा था या नहीं। यदि यह सही चलता है तो इसका मतलब है कि यह सिस्टम की आवश्यकताओं के अनुसार पूरी तरह से संकलित है।
MotoG कर्नेल संकलन के लिए

नोट: - लिनक्स कर्नेल आवश्यकताओं के अनुसार बदल जाएगा जो सिस्टम हार्डवेयर पर निर्भर करता है


0

एक बार योगदानकर्ता अपनी पैच फाइलें जमा करने के बाद और मर्ज अनुरोध करने के बाद लिनक्स गेटकीपर पैच को एकीकृत और समीक्षा करके देख रहे हैं। यदि यह सफल होता है तो वे पैच को संबंधित शाखा में विलय कर देंगे और नया संस्करण जारी करेंगे। लिनक्स टेस्ट प्रोजेक्ट ( https://github.com/linux-test-project/ltp ) मुख्य स्रोत है जो पैच लगाने के बाद कर्नेल के खिलाफ चलने के लिए परीक्षण परिदृश्य (टेस्ट केस) प्रदान करता है। इसमें लगभग 2 ~ 4 घंटे लग सकते हैं और निर्भर करता है। कृपया ध्यान दें कि चयनित कर्नेल की फ़ाइल प्रणाली किसके खिलाफ परीक्षण करने जा रही है। Ex: Ext4, EXT3 और इसी तरह के विभिन्न परिणामों को उत्पन्न करता है।

कर्नेल परीक्षण प्रक्रिया।

  1. भंडार से नवीनतम कर्नेल स्रोत प्राप्त करें। ( https://www.kernel.org/ या Github.com)
  2. पैच फ़ाइल लागू करें (डिफ टूल का उपयोग करके)
  3. नई गिरी बनाएँ।
  4. LTP ( https://github.com/linux-test-project/ltp ) में परीक्षण प्रक्रियाओं के विरुद्ध परीक्षण
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.