[0/3] Turn CONFIG_HOTPLUG always on.
mbox series

Message ID 20120904234803.554552301@clark.kroah.org
Headers show
Series
  • Turn CONFIG_HOTPLUG always on.
Related show

Message

Greg Kroah-Hartman Sept. 5, 2012, 12:01 a.m. UTC
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.

thanks,

greg k-h

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

Comments

Greg Kroah-Hartman Sept. 6, 2012, 8:28 p.m. UTC | #1
On Tue, Sep 04, 2012 at 05:01:05PM -0700, Greg Kroah-Hartman wrote:
> 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.

thanks,

greg k-h
--
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/
Andrew Morton Oct. 5, 2012, 8:50 a.m. UTC | #2
On Thu, 6 Sep 2012 13:28:16 -0700 Greg KH <gregkh@linuxfoundation.org> wrote:

> On Tue, Sep 04, 2012 at 05:01:05PM -0700, Greg Kroah-Hartman wrote:
> > 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.

Tim, do you know?
--
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/
Greg Kroah-Hartman Oct. 5, 2012, 2:32 p.m. UTC | #3
On Fri, Oct 05, 2012 at 01:50:36AM -0700, Andrew Morton wrote:
> On Thu, 6 Sep 2012 13:28:16 -0700 Greg KH <gregkh@linuxfoundation.org> wrote:
> 
> > On Tue, Sep 04, 2012 at 05:01:05PM -0700, Greg Kroah-Hartman wrote:
> > > 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
--
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/