Re: [PATCH 11/14] block: implement and use [__]blk_end_request_all()

[Bartlomiej Zolnierkiewicz]

On Sunday 15 March 2009, Jens Axboe wrote:
> On Sat, Mar 14 2009, Bartlomiej Zolnierkiewicz wrote:
> > On Saturday 14 March 2009, James Bottomley wrote:
> > > On Sat, 2009-03-14 at 20:23 +0100, Bartlomiej Zolnierkiewicz wrote:
> > > > > > More generic comment follows -> this patch is guaranteed to clash
> > > > > > with at least linux-next/pata-2.6 tree so why not introduce block
> > > > > > layer helpers now, then push all driver updates through respective
> > > > > > driver maintainers and deal with end_request() later (after all
> > > > > > driver updates are in-tree)?
> > > > > 
> > > > > Most of the lld changes being trivial, I was hoping to push things
> > > > > through blk tree, but IDE seems to be the most intertwined with the
> > > > > block layer and it's likely to see quite some amount of not-so-trivial
> > > > > changes to subtle paths.  How about pushing !IDE parts into blk tree
> > > > > and pulling blk into pata-2.6, make IDE related changes there and
> > > > > pulling back into blk tree so that further progresses can be made?
> > > > 
> > > > There is a "tiny" problem with this -- pata-2.6 is a quilt tree based on
> > > > Linus' tree and it is not going to change for now (for various reasons).
> > > 
> > > Actually this one's easily solvable if you base the quilt on the block
> > > tree (just specify it to linux-next in the BASE directive and it will do
> > > the right thing).
> > > 
> > > What I'd do is actually run two quilts: one based on vanilla and one
> > > based on block and only add block dependent patches to the latter.  This
> > > is like running a postmerge git tree (you can only send a pull request
> > > for it after block goes in).
> > 
> > Thanks for the hint but it sounds like a major pain once you hit some
> > changes touching the same code areas that block patches do...
> > 
> > Besides this is guaranteed to inrease the workload on my side so it
> > won't happen simply because of -ENOTIME.
> 
> When things collide, it is more work for everyone. But such is life for
> middle/core layer changes. Rebasing _really_ should not be a lot of
> work. And you are going to have to do it sooner or later, either upfront
> or after your patches stop applying because the block changes went
> upstream.

The task of running the secondary tree is not merely rebasing of patches
(which I already do on a daily basis) as it also involves extra coordination,
testing, updates etc.

Really, no more IDE workload on my side is possible and this is a fact not
something to be discussed about (unless someone is willing to help with IDE
maintainance tasks or sponsor my kernel work).

> The only sane way to handle conflicts like this is from the bottom and
> up.
> 
> You could try a more helpful approach, Bart.

Well, see my initial reply.  I proposed the middle-point approach which would
spread an extra effort across all parties involved and should also result in
a better review/testing of changes...

Thanks,
Bart
--
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/