On Sun, 01 May, at 10:03:55AM, Ard Biesheuvel wrote: > > Apologies for only mentioning this now, but I wonder why we need this > in the kernel in the first place? The UEFI spec defines 'BootNext' as > the way to set the boot entry for the next boot only, and this could > also be set from userland. (i.e., the agent that knows how to invoke > reboot with this particular string argument could simply set the EFI > variable from userspace) Right, I raised this general point when Stefan sent the patch originally. Specifically, I asked why this can't be solved entirely in userspace and Stefan replied, : It is possible, but that means modifying those userspace apps :) : There are reboot implementations that do "reboot <reason>", such as : Android's reboot command [1] and Upstart's reboot replacement [2], which : pass the reason as an argument to the reboot syscall. : Probably your first question will be - "Why don't you modify those : apps?" Well, I don't see platform-agnostic way how those could be : modified to pass the reason to the bootloader, regardless of platform or : bootloader. The difference with BootNext is that setting BootNext requires smarts in the OS to pick the next boot entry. This driver allows the boot loader to make that call. > As far as reboot/shutdown is concerned, there is a ResetSystem() > runtime service which reboots via the UEFI firmware, which seems like > a better place to record the reboot/shutdown value. But remember, on x86 we rarely use ResetSystem() because of the firmware bugs we've hit in the past. Users may want this driver even though ResetSystem() isn't used to reboot the machine. > So what bootloader is this exactly that requires this? I think gummiboot and the android boot loader can make use of it, but none require it. -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|