linux-kernel - Re: Announce: Linux-next (Or Andrew's dream :-))

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]

Message-Id: <1202828848.3137.4.camel@localhost.localdomain>
Date:	Tue, 12 Feb 2008 09:07:27 -0600
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Greg KH <greg@...ah.com>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	LKML <linux-kernel@...r.kernel.org>, linux-next@...r.kernel.org,
	linux-arch@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus <torvalds@...ux-foundation.org>
Subject: Re: Announce: Linux-next (Or Andrew's dream  :-))

On Mon, 2008-02-11 at 21:53 -0800, Greg KH wrote:
> > this is why you need specific trees for just the API change, and these
> > need to EXPLICITLY go first before EVERYTHING ELSE. Yes this needs a
> > bit of coordination, but it's the only way.
> 
> Even then, it will not work.
> 
> Again, Roland isn't going to want to always pull in my driver tree just
> to build his tree.  He wants to, and needs to do his own development
> effort.
> 
> But when we merge them together, there would be problems.
> 
> So, you can't just "drop" the IB tree.
> You can't just "drip" my tree.
> 
> Where do you "fix this up" at?  I can send a patch for the IB tree, but
> Roland can't put it in his tree, and I can't put it in my tree, it needs
> to go _after_ both of our trees.

Actually, we had exactly this issue with the SCSI bidirectional patches:
They depended on the sg_table patches in block.  The solution I adopted
was two merge trees:  One to go in immediately with no dependencies
(scsi-misc-2.6) and the other based on the pieces of block (so it would
compile and apply) to go in mid way through the merge round after block
(scsi-bidi-2.6).  What I did was keep rebasing the bidi tree until I
could see there was nothing other than a plane base before merging it.

Of course, this only worked because Jens has a git tree ... it would
have been a lot harder (but not impossible) if I'd had entangled patches
from a quilt tree.

So I've already proven that the split tree solution is viable, if not
pretty.  The bidi tree had to be rebased an awful lot as the block trees
changed and rebased.  Unfortunately, git isn't very good at this, I
eventually had to keep a base and a top reference and just try to cherry
pick this series into the new constructed block tree.  But it can be
done...

> That's what -mm has been able to handle so far, and that needs to also
> work with -next.

Actually, we never successfully got block and bidi via -mm.

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/