Re: 2.6.17-rc1-mm1: KEXEC became SMP-only

[Zachary Amsden <zach@vmware.com>]

Andrew Morton wrote:
> Zachary Amsden <zach@vmware.com> wrote:
>   
> > Andrew Morton wrote:
> >     
> > > >  struct subarch_hooks subarch_hook_vector = {
> > > >       .machine_power_off = machine_power_off,
> > > >       .machine_halt = machine_halt,
> > > >       .machine_irq_setup = machine_irq_setup,
> > > >       .machine_subarch_setup = machine_subarch_probe
> > > >       ...
> > > >  };
> > > >
> > > >  And machine_subarch_probe can dynamically change this vector if it 
> > > >  confirms that the platform is appropriate?
> > > >     
> > > >         
> > > I don't recall anyone expressing any desire for the ability to set these
> > > things at runtime.  Unless there is such a requirement I'd suggest that the
> > > best way to address Eric's point is to simply rename the relevant functions
> > > from foo() to subarch_foo().
> > >   
> > >       
> > Avoiding the runtime assignment isn't possible if you want a generic 
> > subarch that truly can run on multiple different platforms.
> >     
>
> Well as I said - I haven't seen any requirement for this expressed.  That
> doesn't mean that such a requirements doesn't exist, of course.
>
>   
> > I prefer runtime assignment not for this reason, but simply because it 
> > also eliminates two artifacts:
> >
> > 1) You can add new subarch hooks without breaking every other 
> > sub-architecture
> >     
>
> Is that useful?   If you need a new subarch_bar() then
>
> a) Implement it in the subarch which needs it
> b) Implement an attribute(weak) stub in a new subarch-stubs.c
> c) call it.
>
> That's a little more costly than a static inline stub, but not much.  Are
> there likely to be any subarch calls which are a) called frequently and b)
> not required on some subarchs?
>   

No, most of these are one time init calls.  The problem before was the 
default subarch couldn't define weak symbols, since setup.c was in the 
subarch itself and not in arch/i386/kernel.  Do weak symbols work with 
all tool chains?

>   
> > 2) You don't need #ifdef SUBARCH_FUNC_FOO goo to do this (renaming 
> > voyager_halt -> default)
> >     
>
> Why would one need that?  Isn't it simply a matter of renaming
> machine_halt() to subarch_machine_halt() everywhere?
>   

No - if you rename machine_halt to subarch_machine_halt, you again can't 
add a new subarch interface without changing all subarchitectures.  If I 
add voyager_smp_bless_voyage(), I now need to add #define 
visws_smp_bless_voyage default_smp_bless_voyage, ... or did you mean 
subarch_machine_halt literally?

> I'm just looking for the simplest option here.  Eric has identified a code
> maintainability problem - it'd be good to fix that, but we shouldn't add
> runtime cost/complexity unless we actually gain something from it.
>   

I think weak symbols are the best approach, if they indeed work with all 
tool chains.

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