Message-Id: <200903152134.46385.bzolnier@gmail.com>
Date:	Sun, 15 Mar 2009 21:34:46 +0100
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	Jens Axboe <jens.axboe@...cle.com>
Cc:	James Bottomley <James.Bottomley@...senpartnership.com>,
	Tejun Heo <tj@...nel.org>, linux-kernel@...r.kernel.org,
	Russell King <rmk@....linux.org.uk>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Mike Miller <mike.miller@...com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Jeff Garzik <jgarzik@...ox.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Jeremy Fitzhardinge <jeremy@...source.com>,
	Alex Dubov <oakad@...oo.com>
Subject: Re: [PATCH 11/14] block: implement and use [__]blk_end_request_all()

On Sunday 15 March 2009, Jens Axboe wrote:
> On Sun, Mar 15 2009, Bartlomiej Zolnierkiewicz wrote:
> > 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.
> 
> Coordination with whom? If people develop off your pata tree, then there
> should be no difference.

Coordination between trees.

Moreover people often develop against linux-next (this is perfectly fine with
the current development model) which after change would mean that their patches
could end up being dependent also on block (more work for me to sort it out).

> > 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).
> 
> Rate of ide/ changes is pretty high, so I'd say you are doing quite well
> on that account.

The historical rate of change have very little to do with the fact that I'm
currently very time constrained.

> > > 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...
> 
> That approach makes sense for more involved changes. Honestly, all it
> would do in this case is slow things down and create more work for Tejun
> or me. Potentially a lot, at least a lot more than the little extra
> effort it would be to rebase the pata tree.

It could be "the little extra effort" after things settle down but not for
the transition period so asking me to do it now is just plain wrong.  Sorry
but we are week or so before merge window and I have to prepare for it!

> Bart, we use this approach all the time with the SCSI branch and it has
> worked fine. It's not going to change for the ide tree. It's
> contradictory to fanning out work at the ends.

I can look into separate trees (or maybe just having one tree based on block
tree like discussed before) after 2.6.30-rc1/2.

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