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

[Andrew Morton]

Zachary Amsden <zach@xxxxxxxxxx> 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?

> 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?

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.
-
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/