[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121121191542.GA23422@kroah.com>
Date: Wed, 21 Nov 2012 11:15:42 -0800
From: Greg KH <gregkh@...uxfoundation.org>
To: Bill Pemberton <wfp5p@...idian.itc.virginia.edu>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Grant Likely <grant.likely@...retlab.ca>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 000/493] remove CONFIG_HOTPLUG as an option
On Wed, Nov 21, 2012 at 01:41:46PM -0500, Bill Pemberton wrote:
> Andrew Morton writes:
> >
> > On Tue, 20 Nov 2012 10:46:11 +0000 Grant Likely <grant.likely@...retlab.ca> wrote:
> >
> > > On Sat, Nov 17, 2012 at 12:19 AM, Bill Pemberton <wfp5p@...ginia.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.
> >
> > Yeah, this is dopey. Send the script to Linus and ask him to run it
> > seven seconds before he releases -rc1, when everyone's trees are
> > empty(ish). Or send him a single megapatch at that time.
> >
>
> I like the script idea for removing all the __dev markings. Creating
> the patches in the first place was a game of whack-a-mole as various
> trees changed.
Linus doesn't like to take scripts, I had planned on queueing all of
these up that different subsystems maintainers didn't take, and pushing
the ones that did merge cleanly into -rc1. Then, right after -rc1 is
out, go through the tree once more to get the stragglers.
Sound reasonable?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists