Messages in this thread | | | From | Grant Likely <> | Date | Tue, 20 Nov 2012 10:46:11 +0000 | Subject | Re: [PATCH 000/493] remove CONFIG_HOTPLUG as an option |
| |
On Sat, Nov 17, 2012 at 12:19 AM, Bill Pemberton <wfp5p@virginia.edu> 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.
| |