qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 27/29] qemu-io: New command 'sleep'


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v3 27/29] qemu-io: New command 'sleep'
Date: Mon, 20 Jan 2014 10:58:20 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Am 18.01.2014 um 00:55 hat Max Reitz geschrieben:
> On 17.01.2014 15:15, Kevin Wolf wrote:
> >There is no easy way to check that a request correctly waits for a
> >different request. With a sleep command we can at least approximate it.
> >
> >Signed-off-by: Kevin Wolf <address@hidden>
> >---
> >  qemu-io-cmds.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 42 insertions(+)
> >
> >diff --git a/qemu-io-cmds.c b/qemu-io-cmds.c
> >index 85e4982..978a3a0 100644
> >--- a/qemu-io-cmds.c
> >+++ b/qemu-io-cmds.c
> >@@ -12,6 +12,7 @@
> >  #include "block/block_int.h"
> >  #include "block/qapi.h"
> >  #include "qemu/main-loop.h"
> >+#include "qemu/timer.h"
> >  #define CMD_NOFILE_OK   0x01
> >@@ -2038,6 +2039,46 @@ static const cmdinfo_t abort_cmd = {
> >         .oneline        = "simulate a program crash using abort(3)",
> >  };
> >+static void sleep_cb(void *opaque)
> >+{
> >+    bool *expired = opaque;
> >+    *expired = true;
> >+}
> >+
> >+static int sleep_f(BlockDriverState *bs, int argc, char **argv)
> >+{
> >+    char *endptr;
> >+    long ms;
> >+    struct QEMUTimer *timer;
> >+    bool expired = false;
> >+
> >+    ms = strtol(argv[1], &endptr, 0);
> >+    if (ms < 0 || *endptr != '\0') {
> >+        printf("%s is not a valid number\n", argv[1]);
> >+        return 0;
> >+    }
> >+
> >+    timer = timer_new_ns(QEMU_CLOCK_HOST, sleep_cb, &expired);
> >+    timer_mod(timer, qemu_clock_get_ns(QEMU_CLOCK_HOST) + SCALE_MS * ms);
> >+
> >+    while (!expired) {
> 
> I don't know whether compilers don't optimize accesses to variables
> whose addresses have been given to other functions, but shouldn't
> expired be marked volatile just to be sure?

That would be a pretty broken compiler, and we're already using the same
pattern all over qemu without volatile, so no. (And if there was a
problem, I guess we'd rather use barriers than volatile variables.)

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]