qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Christophe de Dinechin <dinechin@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Eduardo Habkost" <ehabkost@redhat.com>,
	qemu-trivial@nongnu.org, "Cleber Rosa" <crosa@redhat.com>,
	"Michael Tokarev" <mjt@tls.msk.ru>,
	qemu-devel@nongnu.org,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Richard Henderson" <rth@twiddle.net>,
	"Laurent Vivier" <laurent@vivier.eu>
Subject: Re: [PATCH 01/10] modules: Provide macros making it easier to identify module exports
Date: Tue, 30 Jun 2020 15:39:10 +0200	[thread overview]
Message-ID: <lybll0d669.fsf@redhat.com> (raw)
In-Reply-To: <20200630052756-mutt-send-email-mst@kernel.org>


On 2020-06-30 at 11:38 CEST, Michael S. Tsirkin wrote...
> On Fri, Jun 26, 2020 at 06:42:58PM +0200, Christophe de Dinechin wrote:
>> In order to facilitate the move of large chunks of functionality to
>> load modules, it is simpler to create a wrapper with the same name
>> that simply relays the implementation. For efficiency, this is
>> typically done using inline functions in the header for the
>> corresponding functionality. In that case, we rename the actual
>> implementation by appending _implementation to its name. This makes it
>> easier to select which function you want to put a breakpoint on.
>>
>> Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
>> ---
>>  include/qemu/module.h | 24 ++++++++++++++++++++++++
>>  1 file changed, 24 insertions(+)
>>
>> diff --git a/include/qemu/module.h b/include/qemu/module.h
>> index 011ae1ae76..1922a0293c 100644
>> --- a/include/qemu/module.h
>> +++ b/include/qemu/module.h
>> @@ -39,6 +39,30 @@ static void __attribute__((constructor)) do_qemu_init_ ## function(void)    \
>>  }
>>  #endif
>>
>> +#ifdef CONFIG_MODULES
>> +/* Identify which functions are replaced by a callback stub */
>> +#ifdef MODULE_STUBS
>> +#define MODIFACE(Ret,Name,Args)                                         \
>> +    Ret (*Name)Args;                                                    \
>> +    extern Ret Name##_implementation Args
>> +#else /* !MODULE_STUBS */
>> +#define MODIFACE(Ret,Name,Args)                                         \
>> +    extern Ret (*Name)Args;                                             \
>> +    extern Ret Name##_implementation Args
>> +#endif /* MODULE_STUBS */
>> +
>> +#define MODIMPL(Ret,Name,Args)                                          \
>> +    static void __attribute__((constructor)) Name##_register(void)      \
>> +    {                                                                   \
>> +        Name = Name##_implementation;                                   \
>> +    }                                                                   \
>> +    Ret Name##_implementation Args
>> +#else /* !CONFIG_MODULES */
>> +/* When not using a module, such functions are called directly */
>> +#define MODIFACE(Ret,Name,Args)         Ret Name Args
>> +#define MODIMPL(Ret,Name,Args)          Ret Name Args
>> +#endif /* CONFIG_MODULES */
>> +
>>  typedef enum {
>>      MODULE_INIT_MIGRATION,
>>      MODULE_INIT_BLOCK,
>
> Hmm that's quite a bit of overhead for each call across modules.

Do you mean runtime overhead, i.e. the difference between
foo(x) and (*foo)(x)?


> Can't code patching be used somehow?

I've considered it, but this seems like a bit of a hammer for half a dozen
calls that are mostly init, so not performance sensitive.

In the old times, ld.so used to do that for you. All you had to do was to
mark one symbol as weak. Apparently for security reasons, that feature was
dropped several years ago. At least, that put call patching where it
belonged, i.e. in the loader.

>
>
>> --
>> 2.26.2


--
Cheers,
Christophe de Dinechin (IRC c3d)



  reply	other threads:[~2020-06-30 13:48 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-26 16:42 [PATCH 00/10] RFC: Move SPICE to a load module Christophe de Dinechin
2020-06-26 16:42 ` [PATCH 01/10] modules: Provide macros making it easier to identify module exports Christophe de Dinechin
2020-06-29 10:13   ` Claudio Fontana
2020-06-30 13:48     ` Christophe de Dinechin
2020-06-30  9:38   ` Michael S. Tsirkin
2020-06-30 13:39     ` Christophe de Dinechin [this message]
2020-06-26 16:42 ` [PATCH 02/10] minikconf: Pass variables for modules Christophe de Dinechin
2020-06-26 16:43 ` [PATCH 03/10] spice: Make spice a module configuration Christophe de Dinechin
2020-06-26 16:43 ` [PATCH 04/10] spice: Move all the spice-related code in spice-app.so Christophe de Dinechin
2020-06-26 17:20   ` Daniel P. Berrangé
2020-06-29  9:22     ` Christophe de Dinechin
2020-06-29  9:47       ` Daniel P. Berrangé
2020-06-29 23:37   ` Gerd Hoffmann
2020-06-26 16:43 ` [PATCH 05/10] build: Avoid build failure when building drivers as modules Christophe de Dinechin
2020-06-26 17:23   ` Daniel P. Berrangé
2020-06-29 23:26     ` Gerd Hoffmann
2020-06-26 16:43 ` [PATCH 06/10] trivial: Remove extra trailing whitespace Christophe de Dinechin
2020-06-29  9:56   ` Philippe Mathieu-Daudé
2020-06-26 16:43 ` [PATCH 07/10] qxl - FIXME: Build as module Christophe de Dinechin
2020-06-26 16:43 ` [PATCH 08/10] build: Add SPICE_CFLAGS and SPICE_LIBS to relevant files Christophe de Dinechin
2020-06-26 17:26   ` Daniel P. Berrangé
2020-06-29  9:27     ` Christophe de Dinechin
2020-06-29 23:08   ` Gerd Hoffmann
2020-06-30 13:56     ` Christophe de Dinechin
2020-06-26 16:43 ` [PATCH 09/10] spice: Put spice functions in a separate load module Christophe de Dinechin
2020-06-26 17:35   ` Daniel P. Berrangé
2020-06-29 17:19     ` Christophe de Dinechin
2020-06-29 17:30       ` Daniel P. Berrangé
2020-06-29 23:00       ` Gerd Hoffmann
2020-06-30 12:54         ` Christophe de Dinechin
2020-06-26 16:43 ` [PATCH 10/10] REMOVE: Instrumentation to show the module functions being replaced Christophe de Dinechin
2020-06-26 17:29   ` Daniel P. Berrangé
2020-06-30 12:48     ` Christophe de Dinechin

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=lybll0d669.fsf@redhat.com \
    --to=dinechin@redhat.com \
    --cc=crosa@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=laurent@vivier.eu \
    --cc=marcandre.lureau@redhat.com \
    --cc=mjt@tls.msk.ru \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@nongnu.org \
    --cc=rth@twiddle.net \
    /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).