You are right. We should add some simple support for handling uninterrupted sequences. I will have a look at adding something like that over the next week. regards ronnie sahlberg On Fri, Dec 7, 2012 at 11:31 AM, Arne Redlich <arne.redlich@xxxxxxxxxxxxxx> wrote: > 2012/12/7 Ronnie Sahlberg <ronniesahlberg@xxxxxxxxx>: >> Fix the compare and write opcode but leave it disabled. >> It looks like consumers like vmware may be assuming that IF >> compare and write is present and if it works, then the target will also >> implement other opcodes like XCOPY etc. >> >> So lets fix the command so that it works, but wait with enabling it >> until we have everything else that the main consumer of this rare opcode >> expects and wants. >> >> Signed-off-by: Ronnie Sahlberg <ronniesahlberg@xxxxxxxxx> >> --- >> usr/bs_rdwr.c | 21 +++++++++++++++++---- >> 1 files changed, 17 insertions(+), 4 deletions(-) > > I suppose this fell through the cracks last time around since I didn't > get any feedback: how is atomicity of the CAW guaranteed? AFAIU, > another bs thread could modify the data while a CAW is going on, > breaking the expected semantics. Or am I just overlooking something in > the code? > > Thanks, > Arne -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
