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
[-- Attachment #1: xtensa-remove-duplicate-config_hotplug-definition.patch --] [-- Type: text/plain, Size: 1508 bytes --] From: Greg KH <gregkh@linuxfoundation.org> As part of the plan to remove CONFIG_HOTPLUG, it was found that xtensa duplicates this config option for no reason (it's already defined as part of init/Kconfig). This patch removes it from the xtensa-only Kconfig file. Cc: Chris Zankel <chris@zankel.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- arch/xtensa/Kconfig | 18 ------------------ 1 file changed, 18 deletions(-) --- a/arch/xtensa/Kconfig +++ b/arch/xtensa/Kconfig @@ -172,24 +172,6 @@ config CMDLINE source "mm/Kconfig" -config HOTPLUG - bool "Support for hot-pluggable devices" - help - Say Y here if you want to plug devices into your computer while - the system is running, and be able to use them quickly. In many - cases, the devices can likewise be unplugged at any time too. - - One well known example of this is PCMCIA- or PC-cards, credit-card - size devices such as network cards, modems or hard drives which are - plugged into slots found on all modern laptop computers. Another - example, used on modern desktops as well as laptops, is USB. - - Enable HOTPLUG and build a modular kernel. Get agent software - (from <http://linux-hotplug.sourceforge.net/>) and install it. - Then your kernel will automatically call out to a user mode "policy - agent" (/sbin/hotplug) to load modules and set up software needed - to use devices as you hotplug them. - source "drivers/pcmcia/Kconfig" source "drivers/pci/hotplug/Kconfig"
[-- Attachment #1: tile-remove-duplicate-config_hotplug-definition.patch --] [-- Type: text/plain, Size: 945 bytes --] From: Greg KH <gregkh@linuxfoundation.org> As part of the plan to remove CONFIG_HOTPLUG, it was found that tile duplicates this config option for no reason (it's already defined as part of init/Kconfig). This patch removes it from the tile-only Kconfig file. Cc: Chris Metcalf <cmetcalf@tilera.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- arch/tile/Kconfig | 8 -------- 1 file changed, 8 deletions(-) --- a/arch/tile/Kconfig +++ b/arch/tile/Kconfig @@ -412,14 +412,6 @@ config TILE_USB config NEED_BOUNCE_POOL def_bool USB_OHCI_HCD -config HOTPLUG - bool "Support for hot-pluggable devices" - ---help--- - Say Y here if you want to plug devices into your computer while - the system is running, and be able to use them quickly. In many - cases, the devices can likewise be unplugged at any time too. - One well-known example of this is USB. - source "drivers/pci/hotplug/Kconfig" endmenu
[-- Attachment #1: config_hotplug-should-be-always-on.patch --] [-- Type: text/plain, Size: 1525 bytes --] From: Greg KH <gregkh@linuxfoundation.org> CONFIG_HOTPLUG is a very old option, back when we had static systems and it was odd that any type of device would be removed or added after the system had started up. It is quite hard to disable it these days, and even if you do, it only saves you about 200 bytes. However, if it is disabled, lots of bugs show up because it is almost never tested if the option is disabled. This is a step to eventually just remove the option entirely, which will clean up all of the devinit* variable and function pointer options, that everyone (myself include) ends up getting wrong eventually, causing real problems when memory segments are removed yet we don't expect them to be. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Bjorn Helgaas <bhelgaas@google.com> --- init/Kconfig | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) --- a/init/Kconfig +++ b/init/Kconfig @@ -1201,13 +1201,7 @@ config KALLSYMS_ALL Say N unless you really need all symbols. config HOTPLUG - bool "Support for hot-pluggable devices" if EXPERT - default y - help - This option is provided for the case where no hotplug or uevent - capabilities is wanted by the kernel. You should only consider - disabling this option for embedded systems that do not use modules, a - dynamic /dev tree, or dynamic device discovery. Just say Y. + def_bool y config PRINTK default y
On 9/4/2012 8:01 PM, Greg Kroah-Hartman wrote: > From: Greg KH <gregkh@linuxfoundation.org> > > As part of the plan to remove CONFIG_HOTPLUG, it was found that tile > duplicates this config option for no reason (it's already defined as part of > init/Kconfig). This patch removes it from the tile-only Kconfig file. > > Cc: Chris Metcalf <cmetcalf@tilera.com> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > --- > arch/tile/Kconfig | 8 -------- > 1 file changed, 8 deletions(-) Acked-by: Chris Metcalf <cmetcalf@tilera.com> -- Chris Metcalf, Tilera Corp. http://www.tilera.com
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
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?
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