lkml.org 
[lkml]   [2013]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -v5 5/5] Make reboot_cpuid a kernel parameter.
On Wed, Apr 17, 2013 at 05:39:33PM -0700, H. Peter Anvin wrote:
> On 04/17/2013 05:17 PM, Robin Holt wrote:
> >
> > There are 4 items being parsed out of reboot= for x86:
> > - reboot_mode w[arm] | c[old]
> > - reboot_cpu s[mp]####
> > - reboot_type b[ios] | a[cpi] | k[bd] | t[riple] | e[fi] | p[ci]
> > - reboot_force f[orce]
> >
> > This seems like a lot to push into the generic kernel just to make it
> > appear consistent when there will be no real cross arch consistency.
> >
> > Contrast that with:
> > 1) New kernel parameter (reboot_cpu) which is clear and concise, uses standard
> > parsing methods.
> > 2) Backwards compatibility in that a user with an existing (broken) reboot=s32
> > on the command line will set reboot_cpu unless both were specified, in which
> > case reboot_cpu takes precedence.
> >
> > What is so fundamentally wrong with that? It accomplishes exactly what
> > you had asked for in that existing users are not broken. We are introducing
> > a new functionality in the general kernel. Why not introduce a new parameter
> > associated with that functionality.
> >
>
> You are confusing implementation with interface. That is what is so
> fundamentally wrong with that. You really, really don't want to change
> interface unless the world will end if you don't.
>
> As far as why centralize -- the main concern I have is that someone
> might try to introduce an arch-specific reboot= which is *syntactically*
> different, which is yet again really awful from a user perspective.

Yes and no. I am saying that the interface is garbage and already
specified as arch specific. You are asking me to take that garbage
interface and promote it to a general interface which will force us to
implement it in a completely crappy way.

Compare that with introducing a new interface which is concise and then
providing backwards compatibility. Add to that the fact, I don't need
to pollute the kernel with some poorly done x86 interface and leave that
cruft for others to clean up.

Thanks,
Robin


\
 
 \ /
  Last update: 2013-04-18 03:41    [W:3.389 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site