On 05/08/2013 11:20 AM, Russell King - ARM Linux wrote:

Let's try to get the meaning back.  On ARM, these are taken from the first
letter of the 'reboot=' command line argument, which was initially either
"hard" or "soft".  This refers to whether we hit some bit of hardware
which physically asserts some reset line in the system, or merely vector
the CPU via the reset vector (for some systems, this is the only
possibility.)

Then PXA happened, and there was a need for some platforms there to do
a hardware restart via toggling a GPIO output, which would then ultimately
assert the system reset line.  So we then added the "gpio" mode as well.
reboot via toggling a GPIO output.  So we then ended up with "gpio" as
well.

So, on ARM, the modes are: hard, soft, gpio, which get translated to a
single letter by the simple parsing code:

static char reboot_mode = 'h';

int __init reboot_setup(char *str)
{
        reboot_mode = str[0];
        return 1;
}

__setup("reboot=", reboot_setup);

Now, arguably, "hard" and "soft" have an entirely different meaning to
"warm" and "cold" in the normal parlence.  A "warm" reboot involves the
system doing less tasks at restart than a "cold" reboot.  This is not
necessarily the case between 'hard' and 'soft'.

So, while I don't entirely agree with mapping "hard" to "cold" and
"soft" to "warm", I guess for the sake of generalisation it's okay.
However, thinking about the future, if ARM becomes more server-like,
we might also want "cold" and "warm" reboot identifiers too.

I think the solution to this would be to have the new generic code
parse the entire argument, not just the first letter - certainly for
the 's' case.  If it's the x86 version, it'll be "s<number>".  If
it's the ARM version, it should be "soft".

The s<number> thing is pretty awful, admittedly (it was supposed to be
smp<number>, but the parser, rather than *allowing* only the first
letter, seems to *require* that it is only the first letter.)

The problem I see is that we don't know what we'll break if we change
it, but Ingo seems to think it doesn't matter so much.

For the boolean letter argument, we could simply have the parser set a
bitmask of the letters seen; the x86 "s" argument is clearly an outlier.

We could handle it in a generic exception by looking for s<digit> or
smp<digit>, which will not match ARM's "soft" argument.  I suspect we
can worry about other argument-carrying options in a generic fashion
when the need arises; I would personally prefer the "subtag:argument"
format used by libata &c for that, and the presence of a ':' would be
indicative.

	-hpa