प्रिंटक, क्या वाकई यह बुरा है?

Question

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

मेरे पास सवाल है, यही कारण है कि यह क्यों हो रहा है? printk फ़ंक्शन buffered है! इसका मतलब है, जहां तक ​​मैं समझता हूं कि डेटा को कतार में डाला गया है, और इसे बाद में संभाला जा रहा है, संभवतया इंटरप्ट हैंडलर समाप्त होने के बाद।

तो यह क्यों काम नहीं करता है?

Answer 1

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

यदि आपके पास समय की महत्वपूर्ण जगह है जहां आप कुछ डीबग आउटपुट प्राप्त करना चाहते हैं, तो आप आधुनिक कर्नेल में trace_printk फ़ंक्शन का उपयोग कर देख सकते हैं। यह वास्तव में ट्रेस रिंगबफर में इनपुट डालता है, और आप इसे बाद में पढ़ सकते हैं। पूर्ण विवरण के लिए this article पर एक नज़र डालें।

Answer 2

हां, printf से यह बहुत बुरा है, शायद अधिकतर पुनर्वित्त नहीं है। क्या हो सकता है कि मुख्य कार्यक्रम printf कहता है, व्यवधान आता है, जबकि printf निष्पादित हो रहा है, और फिर आईआरक्यू हैंडलर printf फिर से कहता है: बहुत बुरी चीजें (जैसे, गतिरोध, भ्रष्ट आंतरिक बफ़र्स, आदि)