qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/2] qemu-tool: Stub out qemu-timer functions


From: Michael Roth
Subject: Re: [Qemu-devel] [PATCH 1/2] qemu-tool: Stub out qemu-timer functions
Date: Thu, 17 Feb 2011 10:27:28 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7

On 02/17/2011 08:59 AM, Stefan Hajnoczi wrote:
Block drivers may need timers for flushing data to disk or reconnecting
to a network drive.  Stub out the following functions in qemu-tool.c:

QEMUTimer *qemu_new_timer(QEMUClock *clock, QEMUTimerCB *cb, void *opaque)
void qemu_free_timer(QEMUTimer *ts)
void qemu_del_timer(QEMUTimer *ts)
void qemu_mod_timer(QEMUTimer *ts, int64_t expire_time)
int64_t qemu_get_clock(QEMUClock *clock)

They will result in timers never firing when linked against qemu-tool.o.

Signed-off-by: Stefan Hajnoczi<address@hidden>
---
  qemu-tool.c |   24 ++++++++++++++++++++++++
  1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/qemu-tool.c b/qemu-tool.c
index 392e1c9..2e2f2a8 100644
--- a/qemu-tool.c
+++ b/qemu-tool.c
@@ -20,6 +20,7 @@
  #include<sys/time.h>

  QEMUClock *rt_clock;
+QEMUClock *vm_clock;

  FILE *logfile;

@@ -111,3 +112,26 @@ int qemu_set_fd_handler2(int fd,
  {
      return 0;
  }
+
+QEMUTimer *qemu_new_timer(QEMUClock *clock, QEMUTimerCB *cb, void *opaque)
+{
+    return qemu_malloc(1);
+}
+
+void qemu_free_timer(QEMUTimer *ts)
+{
+    qemu_free(ts);
+}
+
+void qemu_del_timer(QEMUTimer *ts)
+{
+}
+
+void qemu_mod_timer(QEMUTimer *ts, int64_t expire_time)
+{
+}
+
+int64_t qemu_get_clock(QEMUClock *clock)
+{
+    return 0;
+}

As an alternative to stubbing, can we consider the following patches which make timers functional for qemu-tools (if you add code to actually drive the timers...otherwise they'll just never fire as is the case with your patches)? These also make qemu_set_fd_handler() available for qemu-tools (again, if you actually drive the select() loop), but you could pull the timer-specific stuff out if that's a bit too out-of-scope for your changes. I could also post these as a separate patchset... I think these may be useful for driving some of the block testing utilities:

___
Move code related to fd handlers into utility functions

This allows us to implement an i/o loop outside of vl.c that can
interact with objects that use qemu_set_fd_handler()

http://repo.or.cz/w/qemu/mdroth.git/commitdiff/2becd511df5f064e32f84e93dc5018933dcb5351

___
Add qemu_set_fd_handler() wrappers to qemu-tools.c

This adds state information for managing fd handlers to qemu-tools.c so
that tools that build against it can implement an I/O loop for
interacting with objects that use qemu_set_fd_handler()

http://repo.or.cz/w/qemu/mdroth.git/commitdiff/fd1e5887e4aaa9dc8b6a25950a3f31b20e4b6390

___
Make qemu timers available for tools

To be able to use qemu_mod_timer() and friends to register timeout
events for virtagent's qemu-va tool, we need to do the following:

Move several blocks of code out of cpus.c that handle initialization
of qemu's io_thread_fd and working with it via
qemu_notify_event()/qemu_event_read()/etc, and make them accessible
as backend functions to both the emulator code and qemu-tool.c via
wrapper functions within cpus.c and qemu-tool.c, respectively. These
have been added to qemu-ioh.c, where similar treatment was given to
qemu_set_fd_handler() and friends.

Some of these wrapper functions lack declarations when being
built into tools, so we add those via qemu-tool.h, which can be included
by a tool to access them. With these changes we can drive timers in a
tool linking it against qemu-timer.o and then implementing something
similar to the main i/o loop in vl.c:

init_clocks();
configure_alarms("dynticks");
if (init_timer_alarm() < 0) {
    errx(EXIT_FAILURE, "could not initialize alarm timer");
}

while (running) {
    //do work
    qemu_run_all_timers();
}

http://repo.or.cz/w/qemu/mdroth.git/commitdiff/65dd692242334806f26e38d6f5cf9bc20c22ec2e



reply via email to

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