On Sun, Jul 1, 2012 at 5:10 PM, NeilBrown <neilb@xxxxxxx> wrote:
> On Fri, 29 Jun 2012 21:37:36 -0700 Colin Cross <ccross@xxxxxxxxxxx> wrote:
>
>> What's the point of the existing syscall option if it doesn't work on
>> all platforms, or at least all platforms that want to support it? It
>> doesn't make sense to me to use REBOOT2 on some SoCs because they
>> happen to use something that userspace cannot access, but use direct
>> access from userspace and a different reboot syscall option on other
>> SoCs.
You missed this part of my message.
>> >> <snip>
>> >>
>> >> >>
>> >> >> diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
>> >> >> index 9a99238..c30fd20 100644
>> >> >> --- a/drivers/staging/android/Kconfig
>> >> >> +++ b/drivers/staging/android/Kconfig
>> >> >> @@ -78,6 +78,17 @@ config ANDROID_INTF_ALARM_DEV
>> >> >> elapsed realtime, and a non-wakeup alarm on the monotonic clock.
>> >> >> Also exports the alarm interface to user-space.
>> >> >>
>> >> >> +config BOOTLOADER_CONTROL
>> >> >> + tristate "Bootloader Control Block module"
>> >> >> + default n
>> >> >> + help
>> >> >> + This driver installs a reboot hook, such that if reboot() is invoked
>> >> >> + with a string argument NNN, "bootonce-NNN" is copied to the command
>> >> >> + field in the Bootloader Control Block on the /misc partition, to be
>> >> >> + read by the bootloader. If the string matches one of the boot labels
>> >> >> + defined in its configuration, it will boot once into that label. The
>> >> >> + device and partition number are specified on the kernel command line.
>> >> >> +
>> >> >> endif # if ANDROID
>> >> >>
>> >> >> endmenu
>> >>
>> >> Most of this driver is not unique to Android.
>> >
>> > Do any other systems use it?
>>
>> None that I'm aware of, but REBOOT2 existed long before Android, so I
>> assume something must have used it.
>
> Dangerous that - making assumptions.
>
> I've just spent a while hunting though the code and the history.
> The LINUX_REBOOT_CMD_RESTART2 option to sys_reboot - which is the only one
> that uses the the 'arg' option - was added in 2.1.30. This was the same time
> that reboot notifiers were added and there seem to be steps towards a more
> generic "machine_restart" call.
> No code actually *used* the arg.
>
> Looking through current code is rather time consuming as you have to follow
> several levels of indirection to find code that might actually use the arg,
> but I spend a while looking, trying to cover samples for all archs and driver
> classes (there are lots of watchdogs - I didn't check them all).
> I only found *1* instance of code which actually used the arg.
> This is arch/alpha/kernel/process.c which tests if the arg is NULL, and
> selects between a "cold bootstrap" and a "warm bootstrap".
>
> I think we would be well served by a patch that just removes it. Or at
> least, that ignores the value of the arg and just passes NULL or (void*)1.
> And definitely don't pass it to the reboot notifiers - no code uses it there.
>
> I can certainly see value in having a standard interface to say "the next
> reboot should boot 'foo' rather than the default". I don't think there is
> any real need for the kernel to provide that interface.
>
> I would suggest that you create
> /sbin/next-boot-image
> (or some better name), which gets a different program installed depending on
> what boot loader is in use. Then your libcutils can just
>
> system("/sbin/next-boot-image foo")
> reboot(LINUX_REBOOT_CMD_RESTART);
>
> and work on all platforms.
> (Or use a loadable module, or a binder RPC to some service, or dbus or smoke
> signals or whatever).
>
On many (most?) ARM SoCs, the reboot flag is not stored on disk, or
anywhere else userspace can access. It is stored in a power
management controller scratch register that survives resets, or a
register in an external I2C PMIC, or in internal SoC RAM (I've seen
all of these). For your proposal, every SoC would need a custom API
to save the reboot flag somewhere. For these devices, it clearly
makes more sense to use something like the REBOOT2 API, and if we have
to use it on some devices, it makes no sense to me to not use it on
other devices just because userspace could theoretically handle it.
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
