On 24/02/14 13:49, Zoltan Kiss wrote:
On 22/02/14 23:18, Zoltan Kiss wrote:
On 18/02/14 17:45, Ian Campbell wrote:
On Mon, 2014-01-20 at 21:24 +0000, Zoltan Kiss wrote:
Re the Subject: change how? Perhaps "handle foreign mapped pages on the
guest RX path" would be clearer.
Ok, I'll do that.
RX path need to know if the SKB fragments are stored on pages from
another
domain.
Does this not need to be done either before the mapping change or at
the
same time? -- otherwise you have a window of a couple of commits where
things are broken, breaking bisectability.
I can move this to the beginning, to keep bisectability. I've put it
here originally because none of these makes sense without the
previous patches.
Well, I gave it a close look: to move this to the beginning as a
separate patch I would need to put move a lot of definitions from the
first patch to here (ubuf_to_vif helper, xenvif_zerocopy_callback
etc.). That would be the best from bisect point of view, but from
patch review point of view even worse than now. So the only option I
see is to merge this with the first 2 patches, so it will be even bigger.
Actually I was stupid, we can move this patch earlier and introduce
stubs for those 2 functions. But for the another two patches (#6 and #8)
it's still true that we can't move them before, only merge them into the
main, as they heavily rely on the main patch. #6 is necessary for
Windows frontends, as they are keen to send too many slots. #8 is quite
a rare case, happens only if a guest wedge or malicious, and sits on the
packet.
So my question is still up: do you prefer perfect bisectability or more
segmented patches which are not that pain to review?
And based on that principle, patch #6 and #8 should be merged there as
well, as they solve corner cases introduced by the grant mapping.
I don't know how much the bisecting requirements are written in stone.
At this moment, all the separate patches compile, but after #2 there
are new problems solved in #4, #6 and #8. If someone bisect in the
middle of this range and run into these problems, they could quite
easily figure out what went wrong looking at the adjacent patches. So
I would recommend to keep this current order.
What's your opinion?
Zoli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/