Re: [PATCH 000/493] remove CONFIG_HOTPLUG as an option

[Grant Likely]

On Sat, Nov 17, 2012 at 12:19 AM, Bill Pemberton <wfp5p@xxxxxxxxxxxx> wrote:
> CONFIG_HOTPLUG is no longer an optional setting.  In order to remove
> it as on option code paths that check CONFIG_HOTPLUG will removed
> along with the attributes __devexit_p, __devexit, __devinitconst, and
> __devinitdata.
>
> I'll save the list from the mailbomb of this huge patchset.  The
> patches themselves are going to Greg KH for the driver core tree.
>
>
> Bill Pemberton (493):
[...]
>  2942 files changed, 11645 insertions(+), 12116 deletions(-)

So, I've got no problem with the reason for the change and I don't
even think you need my ack for the bits that I maintain (though you
have it if you want it). However, this looks like it is going to be
/painful/. First of all it will touch a huge number of files in the
tree. Yes the change is trivial, but it will require manual fixups on
a lot of patches.

It also means that any in-flight patches (on mailing list, in
linux-next, whatever) that use __devinit will get broken by this
series.

Second; this is nearly 500 commits for effectively 1 change. I do not
want to wade through bisect after this goes through. I'm assuming this
whole thing was generated by a script. Does it really need to be split
out so aggressively? For example, I really don't need one patch to
remove __devinit, another to remove __devexit and another still to
remove __devexit_p all applied against each of my subsystems.

Personally, I'd rather see this change be performed far less
aggressively. Yes, remove CONFIG_HOTPLUG, but leave the __devinit*
macros as unconditional empty no-ops. There are only 24 patches
associated with CONFIG_HOTPLUG and that one is actually dangerous to
drivers when it goes away. It is safe to leave the __devinit macros
lie fallow for a bit. Change check-patch to warn against new users of
the macros, but don't do a full tree clean yet.

Even if you do clean them right away, there still needs to be no-op
versions of __devinit* for a while to avoid pain on in-flight changes.
I'd also like to see the changes to each subsystem squashed together.
That at least will cut down the number of individual commits by a
factor of 4.

Greg, what is your plan for merging this series? I assume you wouldn't
drop it dead in the middle of the merge window.

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