On Mon, Feb 24, 2014 at 03:08:31PM +0000, Zoltan Kiss wrote:
On 24/02/14 13:49, Zoltan Kiss wrote:
On 22/02/14 23:18, Zoltan Kiss wrote:Actually I was stupid, we can move this patch earlier and introduce
On 18/02/14 17:45, Ian Campbell wrote:Well, I gave it a close look: to move this to the beginning as a
On Mon, 2014-01-20 at 21:24 +0000, Zoltan Kiss wrote:Ok, I'll do that.
Re the Subject: change how? Perhaps "handle foreign mapped pages on the
guest RX path" would be clearer.
I can move this to the beginning, to keep bisectability. I've
RX path need to know if the SKB fragments are stored onDoes this not need to be done either before the mapping change
pages from another
domain.
or at the
same time? -- otherwise you have a window of a couple of commits where
things are broken, breaking bisectability.
put it here originally because none of these makes sense without
the previous patches.
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.
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?
What's the diff stat if you merge those patches?