On Fri, Oct 05, 2012 at 01:50:36AM -0700, Andrew Morton wrote:

On Thu, 6 Sep 2012 13:28:16 -0700 Greg KH [off-list ref] wrote:

quoted

On Tue, Sep 04, 2012 at 05:01:05PM -0700, Greg Kroah-Hartman wrote:

quoted

From: Greg KH <gregkh@linuxfoundation.org>

The CONFIG_HOTPLUG variable is tough to turn off, and almost all arches
default to it on.

If you turn it off, it saves you a big 200 or so bytes, and then starts
to cause all sorts of problems as the code paths if the option is
disabled is never really tested, and memory segments start to get thrown
away that driver authors assume will always be present.

So, as part of trying to get rid of the option entirely, let's just turn
the option always on.

Note, to do this properly, I found two duplicate definitions of the
option, in the Tile and Xtensa arch files, this patch series removes
those duplicates first.

Anyone object to me just taking these three patches through my
driver-core tree for 3.7?  After this set, I'll start unwinding the
places where CONFIG_HOTPLUG is used and remove the parts that are not
used anymore now that the option can not be turned off.

Given the lack of objection, I've now queued these up for 3.7 and will
start unwinding the CONFIG_HOTPLUG mess.

I wonder if this has had sufficient consideration.

It isn't just 200 bytes, is it?  It's all memory which is marked
__devinit* and __devexit* - that's a tremendous amount of stuff.  We
should quantify it.

It wouldn't surprise me if there are organizations who are using
CONFIG_HOTPLUG=n effectively.  We regularly bust a gut to save a few
bytes and for people who really care about this we're here sending them
backwards a lot further than that.

Given the recent round of patches that I've applied to the tree making
it so that CONFIG_HOTPLUG=n actually boots and works, that were needed
for the past 6+ kernel versions, I find it very unlikely anyone actually
runs a system in this type of configuration, but I would love to hear
from someone who does if they are out there.

greg k-h