From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/2] qemu-tool: Stub out qemu-timer functions
Date: Thu, 17 Feb 2011 10:27:28 -0600 [thread overview]
Message-ID: <4D5D4C70.7050701@linux.vnet.ibm.com> (raw)
In-Reply-To: <1297954788-22670-2-git-send-email-stefanha@linux.vnet.ibm.com>
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<stefanha@linux.vnet.ibm.com>
> ---
> 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
next prev parent reply other threads:[~2011-02-17 16:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-17 14:59 [Qemu-devel] [PATCH 0/2] qed: Periodically flush and clear need check bit Stefan Hajnoczi
2011-02-17 14:59 ` [Qemu-devel] [PATCH 1/2] qemu-tool: Stub out qemu-timer functions Stefan Hajnoczi
2011-02-17 16:27 ` Michael Roth [this message]
2011-02-17 14:59 ` [Qemu-devel] [PATCH 2/2] qed: Periodically flush and clear need check bit Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D5D4C70.7050701@linux.vnet.ibm.com \
--to=mdroth@linux.vnet.ibm.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.