Re: [Patch -v3 4/4] Make reboot_cpuid a kernel parameter.

[Ingo Molnar]

* Robin Holt <holt@xxxxxxx> wrote:

> On Tue, Apr 16, 2013 at 11:01:09AM +0200, Ingo Molnar wrote:
> > 
> > * Robin Holt <holt@xxxxxxx> wrote:
> > 
> > > On Mon, Apr 15, 2013 at 10:47:49AM -0700, H. Peter Anvin wrote:
> > > > We usually don't break working user setups as a matter if policy.  Only if it can't be avoided.
> > > > 
> > > > Robin Holt <holt@xxxxxxx> wrote:
> > > > 
> > > > >On Mon, Apr 15, 2013 at 10:18:31AM -0700, H. Peter Anvin wrote:
> > > > >> Um... doesn't this break anyone who currently depends on this?
> > > > >
> > > > >Yes.  That is also why I kept this separate and not tagged for
> > > > >stable. They would need to start using the more general kernel
> > > > >parameter
> > > > >to get the same functionality.  Should I have done it differently?
> > > 
> > > How about:
> > > Author: Robin Holt <holt@xxxxxxx>
> > > Date:   Mon Apr 15 11:39:33 2013 -0500
> > > 
> > >     Make reboot_cpuid a kernel parameter.
> > >     
> > >     Moving the reboot=s<##> parameter for x86 to a kernel parameter
> > >     proper.  I did not find any other arch that was specifying the
> > >     reboot cpu.
> > >     
> > >     I left a compatibility mode in there.  The new parameter always
> > >     takes precedence.  I also fixed up the current code to support
> > >     up to cpuid's up to the current max of 4096.
> > 
> > Looks pretty nice and clean to me, as the old boot parameter still keeps working.
> > 
> > Mind sending an updated series that includes all the fixes and the Tested-by from 
> > Shawn Guo?
> 
> Will do.  I am still going through the comments from Joe Perches to the
> third patch. [...]

Those fixes looked sensible to me.

> [...]  Already have added the Tested-by to just the first patch. Otherwise, I am 
> ready to send -v4.

Cool, thanks.

Assuming there are no objections from others, this looks like v3.10 material, as 
we are right before the final v3.9 release and this touches core kernel code 
(which is risky in such a late stage). It all needs a few days of testing as well, 
since it affects the reboot path of pretty much every Linux box in existence that 
runs the updated kernel.

Would you like to see this fix backported? If yes then your simpler v1 patch to 
kernel/sys.c from a few days ago should probably be put into the series as patch
#1, partially reverted by patch #2 et al.

Then patch #1 can be sent to -stable in a compact form, not the whole series. The 
end result of the series would not change.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/