From: Paolo Bonzini <pbonzini@redhat.com>
To: Artem Pisarenko <artem.k.pisarenko@gmail.com>, qemu-devel@nongnu.org
Cc: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru>,
Stefan Hajnoczi <stefanha@redhat.com>,
Fam Zheng <famz@redhat.com>, Kevin Wolf <kwolf@redhat.com>,
Max Reitz <mreitz@redhat.com>,
"open list:Block I/O path" <qemu-block@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 2/3] Introduce attributes to qemu timer subsystem
Date: Mon, 15 Oct 2018 10:39:12 +0200 [thread overview]
Message-ID: <5016919e-897c-1b64-ad9a-4721b5692455@redhat.com> (raw)
In-Reply-To: <442bb618199daa309d3191a5ee848e659a46c0ce.1539528213.git.artem.k.pisarenko@gmail.com>
On 14/10/2018 16:55, Artem Pisarenko wrote:
> Attributes are simple flags, associated with individual timers for their whole lifetime.
> They intended to be used to mark individual timers for special handling by various qemu features operating at qemu core level.
> Existing timer, aio and coroutine interface extended with attribute-enabled variants of functions, which create/initialize timers.
>
> Signed-off-by: Artem Pisarenko <artem.k.pisarenko@gmail.com>
> ---
>
> Notes:
> Conversion and association between QEMUTimerAttrBit and accessor macro are dumb.
> Maybe better alternatives exist (like QFlags in Qt framework) or existing qemu code may be reused, if any.
> Attributes also may be better named as flags, but they looks like something volatile, whereas 'attribute' expresses constant nature better.
>
> include/block/aio.h | 50 +++++++++++++++++++-
> include/qemu/coroutine.h | 5 +-
> include/qemu/timer.h | 110 ++++++++++++++++++++++++++++++++++++++------
> tests/ptimer-test-stubs.c | 7 +--
> util/qemu-coroutine-sleep.c | 6 ++-
> util/qemu-timer.c | 12 +++--
> 6 files changed, 165 insertions(+), 25 deletions(-)
>
> diff --git a/include/block/aio.h b/include/block/aio.h
> index f08630c..a6be3fb 100644
> --- a/include/block/aio.h
> +++ b/include/block/aio.h
> @@ -407,10 +407,35 @@ static inline QEMUTimer *aio_timer_new(AioContext *ctx, QEMUClockType type,
> int scale,
> QEMUTimerCB *cb, void *opaque)
> {
> - return timer_new_tl(ctx->tlg.tl[type], scale, cb, opaque);
> + return timer_new_a_tl(ctx->tlg.tl[type], scale, 0, cb, opaque);
> }
The new function _a_tl is a bit ugly.
I would prefer to:
- only have a new timer_new_full that takes all of scale, attribute and
timerlist
- accept a NULL timerlist and default to main_loop_tlg.tl[type]
- add aio_timer_{new,init}_with_attrs
> diff --git a/include/qemu/coroutine.h b/include/qemu/coroutine.h
> index 9801e7f..cffc2b2 100644
> --- a/include/qemu/coroutine.h
> +++ b/include/qemu/coroutine.h
> @@ -276,7 +276,10 @@ void qemu_co_rwlock_unlock(CoRwlock *lock);
> /**
> * Yield the coroutine for a given duration
> */
> -void coroutine_fn qemu_co_sleep_ns(QEMUClockType type, int64_t ns);
> +#define qemu_co_sleep_ns(type, ns) \
> + qemu_co_sleep_a_ns(type, 0, ns)
> +void coroutine_fn qemu_co_sleep_a_ns(QEMUClockType type, int attributes,
> + int64_t ns);
I wouldn't bother adding co_sleep_a_ns unless it's needed.
> /**
> * Yield until a file descriptor becomes readable
> diff --git a/include/qemu/timer.h b/include/qemu/timer.h
> index 39ea907..031e3a1 100644
> --- a/include/qemu/timer.h
> +++ b/include/qemu/timer.h
> @@ -52,6 +52,28 @@ typedef enum {
> QEMU_CLOCK_MAX
> } QEMUClockType;
>
> +/**
> + * QEMU Timer attributes:
> + *
> + * An individual timer may be assigned with one or multiple attributes when
> + * initialized.
> + * Attribute is a static flag, meaning that timer has corresponding property.
> + * Attributes are defined in QEMUTimerAttrBit enum and encoded to bit set,
> + * which used to initialize timer, stored to 'attributes' member and can be
> + * retrieved externally with timer_get_attributes() call.
> + * Values of QEMUTimerAttrBit aren't used directly,
> + * instead each attribute in bit set accessed with QEMU_TIMER_ATTR(id) macro,
> + * where 'id' is a unique part of attribute identifier.
I think QEMU_TIMER_ATTR is an unnecessary complication. I would just
add a TIMER_ATTR_EXTERNAL constant.
Paolo
next prev parent reply other threads:[~2018-10-15 8:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-14 14:55 [Qemu-devel] [PATCH 0/3] Introduce attributes for timers subsystem and remove QEMU_CLOCK_VIRTUAL_EXT clock type Artem Pisarenko
2018-10-14 14:55 ` [Qemu-devel] [PATCH 1/3] Revert some patches from recent series [PATCH v6] "Fixing record/replay and adding reverse debugging", which introduced new virtual clock type for use in external subsystems. These changes breaks desired behavior in non-record/replay usage scenarios Artem Pisarenko
2018-10-14 14:55 ` [Qemu-devel] [PATCH 2/3] Introduce attributes to qemu timer subsystem Artem Pisarenko
2018-10-15 8:39 ` Paolo Bonzini [this message]
2018-10-16 13:03 ` [Qemu-devel] [PATCH v2] " Artem Pisarenko
2018-10-16 13:47 ` Paolo Bonzini
2018-10-14 14:55 ` [Qemu-devel] [PATCH 3/3] Restores record/replay behavior related to special virtual clock processing for timers used in external subsystems Artem Pisarenko
2018-10-15 6:41 ` Artem Pisarenko
2018-10-15 8:51 ` Paolo Bonzini
2018-10-15 8:54 ` [Qemu-devel] [PATCH 0/3] Introduce attributes for timers subsystem and remove QEMU_CLOCK_VIRTUAL_EXT clock type Paolo Bonzini
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=5016919e-897c-1b64-ad9a-4721b5692455@redhat.com \
--to=pbonzini@redhat.com \
--cc=artem.k.pisarenko@gmail.com \
--cc=famz@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pavel.dovgaluk@ispras.ru \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).