लिनक्स रीबूट() सिस्टम कॉल: यह kernel_halt() के बाद do_exit (0) क्यों कॉल करता है?

Question

इस से संबंधित है: https://stackoverflow.com/a/13413099/1284631

अब, सवाल यह है:

क्यों रिबूट() सिस्टम कॉल, जब LINUX_REBOOT_CMD_HALT पैरामीटर के साथ कहा जाता है (यहाँ देखें: http://lxr.linux.no/linux+v3.6.6/kernel/sys.c#L480) पहले से ही kernel_halt() कहा जाता है के बाद do_exit(0) बुला रहा है, kernel_halt() पर कॉल करने के लिए stop_this_cpu() पर कॉल करने के लिए उबाल लें (यहां देखें: http://lxr.linux.no/linux+v3.6.6/arch/x86/kernel/process.c#L519), native_machine_halt() के भाग के रूप में (यहां देखें: http://lxr.linux.no/linux+v3.6.6/arch/x86/kernel/reboot.c#L680)।

या, मुझे लगता है कि stop_this_cpu() कभी वापस नहीं आ रहा है (यह एक अनंत लूप के साथ समाप्त होता है)।

तो, यह do_exit(0) है, जिसे केवल kernel_halt() पर अपना काम नहीं किया जाता है और यह वापस आता है? क्यों panic() सीधे इसके बजाय क्यों नहीं?

Answer 1

कुछ विचार:

• हो सकता है कि kernel_halt() वास्तव में, किसी वैध कारण के लिए रोकने के लिए हालांकि मैं किसी भी नहीं सोच सकते हैं मना कर दिया।
• kernel_halt() भी एक हाइपरविजर या कर्नेल से अधिक या बराबर स्तर पर कुछ कहा जा करने के लिए डिज़ाइन किया जा सकता है (शायद कस्टम SMI कोड?)
• शायद kernel_halt() समारोह जल्दी देता है, "समय-निर्धारण" पड़ाव, और वास्तविक हार्डवेयर कुछ हार्डवेयर बाद कुछ हार्डवेयर पर होता है। मुझे असेंबली में डॉस में एटीएक्स पावर ऑफ करने के बारे में पढ़ना याद है - आप पावर ऑफ इंटिएट करने के लिए outb निर्देश जारी करेंगे, लेकिन आपको कुछ nops, एक अंतहीन लूप, या hlt वास्तविक शक्ति के रूप में बाद में होना होगा बाद में कुछ चक्र हो सकता है।
• कॉलिंग प्रक्रिया कर्नेल पैनिक से किसी अन्य तरीके से रीबूट करने में विफलता को संभालने की इच्छा रख सकती है।