linux-kernel - Re: [PATCH 11/14] block: implement and use [__]blk_end_request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 15 Mar 2009 22:34:41 +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:
> > > > > > 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).
> 
> And the difference being? The block tree is in -next in the first place.
> This changeset is not yet, since I haven't had time to do testing on it
> yet. But the tested stuff is usually there for each iteration.

pata tree is based on Linus' tree _not_ on linux-next and this is very
handy when it comes to preparing pull requests.

It could be that I worry needlessly but with ~170 patches in the tree
currently, lack of time and merge window around the corner there is
no wonder that I'm reluctant to any experiments.  However I completely
agree that we should look into the ways of improving the process in
the longer-term.

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/