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:	Sat, 14 Mar 2009 14:56:00 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Cc:	Tejun Heo <tj@...nel.org>, axboe@...nel.dk,
	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 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).

James


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

Powered by Openwall GNU/*/Linux Powered by OpenVZ