Re: [GIT PULL] bcache revert

[Jens Axboe]

On 08/31/2015 01:29 PM, Kent Overstreet wrote:
> On Mon, Aug 31, 2015 at 01:14:07PM -0600, Jens Axboe wrote:
> > On 08/31/2015 01:00 PM, Kent Overstreet wrote:
> > > Linus, please pull; this reverts a patch from Jens that was committed without
> > > CCing be or being mailed out to any of the lists. Said patch wasn't in any way a
> > > functional change and is something that damn well should have been discussed.
> > >
> > > Jens - what the goddamn fuck!? You've never touched the bcache code until now,
> > > and when you finally get interested this is what you do!?
> > >
> > > While I am sympathetic to the arguments in favor of your patch, there _are_ some
> > > damn good reasons I did it the way I did. If you want to have that discussion,
> > > feel free to mail your patch out again after the revert.
> >
> > The patch was part of a larger series that I was working on, and I just
> > wanted to flush out that dependency. Christoph review and acked it, it was
> > by no means a sneaking in of a patch.
>
> I didn't see it until I went to rebase bcachefs onto 4.2 this morning. I triple
> checked; this patch is not in any mailing list archive. And you certainly didn't
> try to contact me. How is that _not_ sneaking it in?

It's a simple cleanup patch, against a dormant driver. It was reviewed 
by Christoph, which is as good as it gets. Yes, it should have been 
posted, but it's not like we are talking about a rewrite or anything of 
that magnitude. You're grossly overreacting. I would do it again.

> > So calm down. Is there a bug? The previous code was crap, having hidden
> > returns in macros is horrible. The upstream bcache code has been effectively
> > unmaintained for more than a year, and THIS patch is now a problem? Get
> > real.
>
> Oh, so you're taking over now? This is the first I've heard of it...

Right, a cleanup patch to make a later series of patches easier, I'm 
surely taking over all of bcache! As mentioned in the previous reply, my 
motivation was to make subsequent patches easier to do. The issue was 
getting rid of the hidden macro return in bcache make_request_fn. That's 
how I stumbled upon this abomination.

> You may say the previous code was crap, but believe it or not I'm not an idiot
> and I had real reasons for doing it that way. For damn sure if you want to start
> changing stuff like this now it shouldn't be too much to ask that you _mail the
> patch out_ so it can be discussed.

We can continue wasting time talking about how you had really good 
reasons for having returns hidden in macros, or you could actually bring 
those reasons to light.

--
Jens Axboe

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