* Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [090316 15:22]:
> On Mon, Mar 16, 2009 at 07:40:24PM +0200, Juha Yrjola wrote:
> > Russell King - ARM Linux wrote:
> >
> >> Right. You are aware that there is already a mechanism for doing this
> >> in the generic kernel (obviously not)?
> >
> > I am. Unfortunately, glibc fails to support this mechanism, as you say.
> > I didn't want to start making such intrusive changes for our trivial
> > need.
>
> Yes, glibc sucks with that - they hide the Linux reboot syscall.
> Luckily, it is accessible via the syscall() interface:
>
> #include <linux/reboot.h>
>
> int sys_reboot(const char *cmd)
> {
> return syscall(SYS_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2C,
> LINUX_REBOOT_CMD_RESTART2, cmd);
> }
>
> >> sys_reboot() with LINUX_REBOOT_CMD_RESTART2 takes a string in addition
> >> to the standard parameters. This string is passed into machine_restart()
> >> which we currently ignore. If LINUX_REBOOT_CMD_RESTART is used, this
> >> string is NULL.
> >>
> >> We could change machine_restart() to pass this parameter through to
> >> arm_pm_restart() and ultimately down to arch_reset().
> >
> > Sure. With RESTART2, I could've even used the reboot notifier chain with
> > an OMAP3-specific driver to store the string.
>
> The notifier chain is called in any case.
>
> > Are you suggesting to get rid of reboot_mode altogether? If not, could
> > we still have the sysfs mechanism? A one-character reboot_mode would be
> > plenty enough for us.
>
> No, reboot mode tells _how_ to perform the reboot - whether that be
> by hardware reset, gpio reset or a soft call via the reset address.
> It's not supposed to tell the boot loader what to do.
So if the reboot mode can't be used for this.. Should we change Juha's
sysfs interface patch to store something else like bootloader_mode?
I guess we cannot use kexec for this either?
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
