On Thu, 2009-05-14 at 19:11 +0300, Boaz Harrosh wrote: > On 05/14/2009 06:35 PM, James Bottomley wrote: > <snip> > >> > >> I see that you rebased by now, though I suspect the fc's blk_end_request > >> call will fail to build if merged with block tree. > > > > Yes, that's the bit we need a postmerge tree for. It has to build on > > it's own in scsi-misc, but it's making use of an API Tejun is altering, > > so the block postmerge has to do the API alteration based on the SCSI > > tree. > > > > Tejun's cleanup is a bit tricky and cross trees wide. It will need to be > completely postponed to post merge which will be a pity since there are > so many patches ontop of it in block-next. Unless we want to sacrifice > the build ability of the tree between block-merge and the fixup to this driver. > > Perhaps you could do a scsi-post-merge tree that has only this driver, already > with the new needed code? If necessary. However, the disadvantage of doing it this way around is that I have to squash together the two patches (FC transport patch and the update to tejun's API) otherwise we get a bisection break. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
