Re: [PATCH] el3_common_init() should be __devinit, not __init

[Sam Ravnborg]

On Sun, Nov 02, 2008 at 10:13:03AM -0800, Linus Torvalds wrote:
> 
> 
> On Sat, 1 Nov 2008, Sam Ravnborg wrote:
> > 
> > For cpuinit/cpuexit the gain turned out to be minimal.
> 
> Quite frankly, I'm not convinced.
> 
> Yeah, yeah, most distro's end up always enabling CPU hotplug due to 
> suspend/resume, but:
> 
>  - desktop PC's aren't where most memory pressures are anyway
> 
>  - on UP, CONFIG_HOTPLUG_CPU isn't on even if you do have suspend/resume
> 
>  - we should still care about embedded devices, and while some of them are 
>    growing up (and having SMP and not caring about a few tens of kB of 
>    memory), I don't think that's a valid argument for the other ones.

I benchmarked by investigating a common arm config and not some bloated
x86 desktop config when analysing the cpuinit/cpuexit case.

Another reason why I like to see cpuinit dropped is that it is misused
all over. __cpuinit are used for two purposes:
- to annotate code/data that is only used in the early init phase if
  HOTPLUG_CPU is not enabled
- to annotate code/data that is only used if HOTPLUG_CPU is enabled

The latter use is plain wrong but I never managed to really get to
the bottom of it.

If we could use our config ssytem in the normals ways to cover
with code that is only used for HOTPLUG_CPU then things would be
much simpler.

When I have done sweep fixing all section mismatchs it has almost
always been cpuinit that has caused me most troubles.
The others has been trivial to deal with.

As Al points out in his reply a full day effort can fix a lot
of the remaining ones.

For devinit/devexit there is in my mind no questions that they
shall remain.

The most important topic to address is to get better detection.
What we can do in modpost is limited :-(

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