Wywołanie systemowe systemu Linux reboot(): dlaczego wywołuje metodę do_exit (0) po kernel_halt()?

Question

Jest to związane z: https://stackoverflow.com/a/13413099/1284631

Teraz pytanie brzmi:

Dlaczego restart() wywołanie systemowe, gdy wywołana z LINUX_REBOOT_CMD_HALT parametru (patrz tutaj: http://lxr.linux.no/linux+v3.6.6/kernel/sys.c#L480) dzwoni do_exit(0) po już nazywane kernel_halt(), jako wywołanie kernel_halt() sprowadza się do wywoływania stop_this_cpu() (patrz tutaj: http://lxr.linux.no/linux+v3.6.6/arch/x86/kernel/process.c#L519), jako część native_machine_halt() (patrz tutaj: http://lxr.linux.no/linux+v3.6.6/arch/x86/kernel/reboot.c#L680).

Albo, wydaje mi się, że stop_this_cpu() nigdy nie wraca (kończy się nieskończoną pętlą).

Tak, to jest do_exit(0) nazywane na wszelki wypadek, gdy kernel_halt() nie wykonuje swojej pracy i powraca? Zamiast tego, zamiast tego, zamiast tego, może to być bezpośrednio?

Answer 1

Kilka pomysłów:

• Być może kernel_halt() odmawia faktycznie zatrzymać dla uzasadnionego powodu, chociaż nie mogę myśleć o żadnych.
• kernel_halt() mogą być zaprojektowane, aby być również nazywane przez hypervisor lub coś na wyższym lub równoważnym poziomie niż jądra (niestandardowy kod SMI może?)
• Być może funkcja kernel_halt() wraca wcześnie, „planowanie” postój, a faktyczne zatrzymanie ma miejsce później na niektórych urządzeniach. Pamiętam, że czytałem o wyłączaniu zasilania ATX w systemie DOS podczas instalacji - wydałbyś instrukcję outb, aby włączyć zasilanie, ale musiałbyś mieć teraz trochę nops, nieskończoną pętlę lub hlt, jako faktyczną moc może się zdarzyć później.
• Proces wywołujący może chcieć obsłużyć brak ponownego uruchomienia w inny sposób niż panika jądra.