On Thu, Sep 7, 2017 at 12:27 PM, Jens Axboe <axboe@xxxxxxxxx> wrote:
>
> Which was committed yesterday? It was not from my tree. I try to keep
> an eye out for potential conflicts or issues.
It was from Andrew, so I'm assuming it was in linux-next. Not as a git
tree, but as the usual akpm branch.
I'm not sure why I didn't see any reports from linux-next about it,
though - and I looked.
There was no actual visible merge problem, because the conflict was
not a data conflict but a semantic one.
But the issue showed up for a trivial allmodconfig build, so it
*should* have been caught automatically.
But it's not even the conflict that annoys me.
It's the *reason* for the conflict - the block layer churn that you
said was done. We've had too much of it.
>> We need *stability* by now, after these crazy changes. Make sure that happens.
>
> I am pushing back, but I can't embargo any sort of API change. This one has
> good reasoning behind it, which is actually nicely explained in the commit
> itself. It's not pointless churn, which I would define as change just for
> the sake of change itself. Or pointless cleanups.
You can definitely put your foot down on any more random changes to
the bio infrastructure. Including for good reasons.
We have had some serious issues in the block layer - and I'm not
talking about the merge conflicts. I'm talking about just the
collateral damage, with things like SCSI having to revert using blk-mq
by default etc.
Christ, things like that are pretty *fundamnetal*, wouldn't you say.
Get those right before doing more churn. And aim to have one or two
releases literally just fixing things, with a "no churn" rule.
Because the block layer really has been a black spot lately.
Linus
