qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@linaro.org>
To: Paolo Bonzini <pbonzini@redhat.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [PATCH 4/4] coroutine: Break inclusion loop
Date: Sat, 17 Dec 2022 18:23:27 +0100	[thread overview]
Message-ID: <010eaba5-8d35-7f45-0962-84f3284951c6@linaro.org> (raw)
In-Reply-To: <CABgObfZ4_8MzP4HP1JNjKb=C0qTXY3zHK=zK+=pYBt3hSYjiGQ@mail.gmail.com>

On 13/12/22 01:34, Paolo Bonzini wrote:
>     On 12/8/22 15:23, Markus Armbruster wrote:
>      > qemu/coroutine.h and qemu/lockable.h include each other.  Neither
>      > header actually needs the other one.
> 
>     qemu/lockable.h wants qemu/coroutine.h because of the reference to
>     qemu_co_mutex_lock/unlock in the QEMU_MAKE_LOCKABLE macro.  Said
>     reference only happens when the macro is used, so strictly speaking
>     only code that uses of qemu/lockable.h's functionality needs to
>     include qemu/coroutine.h.  The order doesn't matter.

[*]

>     qemu/coroutine.h similarly wants qemu/lockable.h only for a macro: it
>     uses QemuLockable for the prototype of qemu_co_queue_wait_impl, but
>     QemuLockable is defined in qemu/typedefs.h.  On the other hand, the
>     qemu_co_queue_wait macro needs QEMU_MAKE_LOCKABLE.  Again, the order
>     does not matter but callers of qemu_co_queue_wait appreciate it if
>     both files are included.
> 
>     So, this is why the inclusion loop works.  This patch makes some
>     files include qemu/coroutine.h even if they only need qemu/lockable.h
>     for QEMU_LOCK_GUARD of a "regular" QemuMutex; for example, linux-user/
>     does not use coroutines, so I'd like to avoid that it includes
>     qemu/coroutine.h.
> 
>     One way is to just keep the cycle.  Another is to break the cycle is
>     as follows:
> 
>     1) qemu/coroutine.h keeps including qemu/lockable.h
> 
>     2) qemu/lockable.h is modified as follows to omit the reference to
>     CoMutex:
> 
>     diff --git a/include/qemu/lockable.h b/include/qemu/lockable.h
>     index 86db7cb04c9c..db59656538a4 100644
>     --- a/include/qemu/lockable.h
>     +++ b/include/qemu/lockable.h
>     @@ -71,9 +71,11 @@ qemu_null_lockable(void *x)
>                     void *: qemu_null_lockable(x),                     
>             \
>                     QemuMutex *: qemu_make_lockable(x, QML_OBJ_(x,
>     mutex)),    \
>                     QemuRecMutex *: qemu_make_lockable(x, QML_OBJ_(x,
>     rec_mutex)), \
>     -             CoMutex *: qemu_make_lockable(x, QML_OBJ_(x,
>     co_mutex)),   \
>     +             QEMU_MAKE_CO_MUTEX_LOCKABLE(x)                       
>           \

Interesting, I ended doing something similar today because this line is
the single sysemu-specific part of this file (user emulation shouldn't
have access to qemu/coroutine.h). So back to [*], the order seems to
matter for user-mode.

>                     QemuSpin *: qemu_make_lockable(x, QML_OBJ_(x, spin)))
> 
>     +#define QEMU_MAKE_CO_MUTEX_LOCKABLE(x)
>     +
>        /**
>         * QEMU_MAKE_LOCKABLE_NONNULL - Make a polymorphic QemuLockable
>         *
> 
>     3) the following hack is added in qemu/coroutine.h, right after
>     including qemu/lockable.h:
> 
>     #undef QEMU_MAKE_CO_MUTEX_LOCKABLE(x)
>     #define QEMU_MAKE_CO_MUTEX_LOCKABLE(x) \
>                    CoMutex *: qemu_make_lockable(x, QML_OBJ_(x, co_mutex)),
> 
> 
>     Neither is particularly pretty, so I vote for leaving things as is with
>     a comment above the two #include directives.
> 
>     Paolo
> 



      parent reply	other threads:[~2022-12-17 17:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-08 14:23 [PATCH 0/4] coroutine: Clean up includes Markus Armbruster
2022-12-08 14:23 ` [PATCH 1/4] coroutine: Clean up superfluous inclusion of qemu/coroutine.h Markus Armbruster
2022-12-08 14:59   ` Stefan Hajnoczi
2022-12-08 17:56     ` Markus Armbruster
2022-12-08 14:23 ` [PATCH 2/4] coroutine: Move coroutine_fn to qemu/osdep.h, trim includes Markus Armbruster
2022-12-08 15:03   ` Stefan Hajnoczi
2022-12-08 14:23 ` [PATCH 3/4] coroutine: Clean up superfluous inclusion of qemu/lockable.h Markus Armbruster
2022-12-08 15:05   ` Stefan Hajnoczi
2022-12-08 14:23 ` [PATCH 4/4] coroutine: Break inclusion loop Markus Armbruster
2022-12-08 15:07   ` Stefan Hajnoczi
     [not found]   ` <2ac0daae-da25-0a31-9a73-8f186cc510e9@redhat.com>
2022-12-13  0:34     ` Paolo Bonzini
2022-12-15  6:49       ` Markus Armbruster
2022-12-17 12:42         ` Paolo Bonzini
2022-12-19  4:23           ` Markus Armbruster
2022-12-17 17:23       ` Philippe Mathieu-Daudé [this message]

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=010eaba5-8d35-7f45-0962-84f3284951c6@linaro.org \
    --to=philmd@linaro.org \
    --cc=armbru@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --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).