On Tue, 2014-06-10 at 12:57 -0700, Nicholas A. Bellinger wrote: > On Tue, 2014-06-10 at 21:45 +0300, Michael S. Tsirkin wrote: > > On Tue, Jun 10, 2014 at 10:39:17AM -0700, Nicholas A. Bellinger wrote: > > > On Tue, 2014-06-10 at 16:02 +0300, Michael S. Tsirkin wrote: > > > > On Tue, Jun 10, 2014 at 09:52:17PM +1000, Stephen Rothwell wrote: > > > > > Hi Michael, > > > > > > > > > > On Tue, 10 Jun 2014 12:42:54 +0300 "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote: > > > > > > > > > > > > So I see two options: > > > > > > - I go ahead with my changes and you with yours and let Linus resolve > > > > > > the conflict. This means bisect build will be broken since the > > > > > > breakage will likely not be noticed until after the merge. > > > > > > > > > > Well, since the resolution is known, the one who submits their tree > > > > > later should tell Linus (as suggested by Nicholas). That is part of > > > > > the point of the linux-next tree ... and therefore there would be no > > > > > bisect problem. > > > > > > > > > > > > Stephen (CC'ed) has included a fix in today's linux-next for the merge > > > > > > > conflict here: > > > > > > > > > > > > > > https://lkml.org/lkml/2014/6/10/3 > > > > > > > > > > > > > > Please confirm, as it will be a pointer to Linus within the > > > > > > > target-pending/for-next PULL request. > > > > > > > > > > > > Yes but this does mean people trying to bisect will > > > > > > hit build breakages, not nice. > > > > > > > > > > Not necessarily. > > > > > > > > > > -- > > > > > Cheers, > > > > > Stephen Rothwell sfr@xxxxxxxxxxxxxxxx > > > > > > > > > > > > I don't see how that's possible. > > > > Here's a point you might have missed. > > > > Nicholas's patch isn't just introducing a merge conflict. > > > > It is also buggy. > > > > Replacing bit access with has_feature silently fixes the bug. > > > > > > > > So if we want to avoid bisect breakage target tree will > > > > have to be rebased. > > > > > > > > And if doing that anyway, I don't see any reason not > > > > to merge everything through the vhost tree, esp > > > > since I already put the patches there. Less work for > > > > everyone involved. > > > > > > > > > > The problem is with Sagi's recent changes wrt to including T10 PI bytes > > > into expected data transfer length in target-core, you'll end up > > > introducing a different bug into your tree.. ;) > > > > > > Why don't I simply add Stephen's patch to use vhost_has_feature() in > > > target-pending/for-next, and we just make sure that the vhost PULL > > > request goes out after target-pending..? > > > > > > --nab > > > > Because that depends on vhost API changes :) > > > > Ugh, right. > > In that case, let's see what Linus (CC'ed) prefers to do.. Build a branch with all the patches dependent on the new API based on top of the vhost tree. Then you send it to Linus after the vhost tree is merged (otherwise you end up being the person sending the vhost tree). That way there's no API breakage and we get a consistent always buildable tree. 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
