Re: Deprecating ipath
From: Greg Kroah-Hartman
Date: Fri Jul 03 2015 - 11:37:00 EST
On Fri, Jul 03, 2015 at 01:25:25PM +0000, Dalessandro, Dennis wrote:
> > -----Original Message-----
> > From: linux-rdma-owner@xxxxxxxxxxxxxxx [mailto:linux-rdma-
> > owner@xxxxxxxxxxxxxxx] On Behalf Of Greg Kroah-Hartman
> > Sent: Friday, June 26, 2015 12:54 PM
> > To: Luis R. Rodriguez
> > Cc: Marciniszyn, Mike; Borislav Petkov; Ingo Molnar; One Thousand Gnomes;
> > Doug Ledford; linux-rdma@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> > Subject: Re: Deprecating ipath
> >
> > On Fri, Jun 26, 2015 at 09:23:27AM -0700, Luis R. Rodriguez wrote:
> > > On Fri, Jun 26, 2015 at 9:17 AM, Marciniszyn, Mike
> > > <mike.marciniszyn@xxxxxxxxx> wrote:
> > > > Doug,
> > > >
> > > > We have been given the go ahead to start the deprecation process for
> > thie ipath driver.
> > >
> > > That's great! Do you mean removal from Linux?
> > >
> > > > What do I need to do to get that done?
> > >
> > > Feature removal txt file was removed from the kernel so there is no
> > > "schedule" per se, not sure what the process these days is for driver
> > > removal. How about punting it to staging for a release or two and then
> > > remove it? Not sure if that would be frowned upon or welcomed.
> >
> > That is the process for driver removal, so of course it is welcomed :)
> >
> > > That would have the cost of moving history through directories but git
> > > --follow helps with that these days. The gain of moving it to staging
> > > IMHO would be that if anyone who might care would need to complain
> > may
> > > do so for a directory change for 1-2 release may spot this easily and
> > > the issues would be much less than an immediate removal.
> >
> > Yes, that's why we do it this way.
> >
> > Mike, feel free to send me a patch for this if you want me to queue it up for
> > 4.3. For 4.2 it's too late.
> >
> > thanks,
> >
> > greg k-h
> > --
>
> Greg, how would you like to consume that patch? There are a number of large
> files. We can break things up into a series and send through email. We could
> also post a repo somewhere that you can do a pull from. Something else?
If you use -M to 'git format-patch' when generating a patch, it will
show that you just moved the files around the directory tree, and the
patch should be quite small and easy to email and review.
In fact, you should use that as a default for all patches, as it's now a
standard that normal patch can use to consume, I have this in my
.gitalias file:
[alias]
fp = format-patch -M
and just use 'git fp' all the time.
try that and see what the results are.
thanks,
greg k-h
--
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/