qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Halil Pasic <pasic@linux.ibm.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Thomas Huth" <thuth@redhat.com>,
	"Boris Fiuczynski" <fiuczy@linux.ibm.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Cornelia Huck" <cohuck@redhat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	qemu-devel@nongnu.org, "Bruce Rogers" <brogers@suse.com>,
	"Christian Borntraeger" <borntraeger@de.ibm.com>,
	qemu-s390x@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"David Hildenbrand" <david@redhat.com>
Subject: Re: [PATCH v2 1/1] hw/s390x: modularize virtio-gpu-ccw
Date: Wed, 3 Mar 2021 15:36:47 +0100	[thread overview]
Message-ID: <20210303153647.626d9aa6.pasic@linux.ibm.com> (raw)
In-Reply-To: <20210303070750.etddrd7duu5ep77l@sirius.home.kraxel.org>

On Wed, 3 Mar 2021 08:07:50 +0100
Gerd Hoffmann <kraxel@redhat.com> wrote:

>   Hi,
> 
> > The only approaches I can think of to make type_register_mayfail()
> > "work" involve adding a dependency check in type_register_internal()
> > before the call to type_table_add() is made. This can "work" for modules,
> > because for types loaded from we can hope, that all dependencies are
> > already, as modules are loaded relatively late.  
> 
> Yes, for modules the lazy binding should not be needed and we should be
> able to check for the parent at registration time.  module.c keeps track
> of whenever phase1 init for builtin qom objects did happen already, so
> we can use that instead of passing mayfail through a bunch of function
> calls.  Quick & dirty test hack below.

Hi Gerd! Thank you very much for your patience. I've sent out a v3 yesterday,
which takes a similar, yet slightly different approach. I will comment
on the proposed diff below. Could you please have a look at my v3? I
would prefer if we can go forward with that solution, but I am more than
willing to prepare a v4 based on this proposal.


> 
> BTW: "qemu-system-x86_64 -device help" tries to load all modules and is
> a nice test case ;)

Yes, I've reported the problem in 
Message-ID: <20210219035206.730f145e.pasic@linux.ibm.com>
using that, for the trace I took -device virtio-gpu-ccw because
the trace looked nicer to me. ;)

> 
> HTH,
>   Gerd
> 
> commit 75ca3012e626318b562bcb51ecdc34400e25f2d0
> Author: Gerd Hoffmann <kraxel@redhat.com>
> Date:   Tue Mar 2 16:26:39 2021 +0100
> 
>     [hack] modular type init check
> 
> diff --git a/qom/object.c b/qom/object.c
> index 491823db4a2d..01785e73f495 100644
> --- a/qom/object.c
> +++ b/qom/object.c
> @@ -135,11 +135,22 @@ static TypeImpl *type_new(const TypeInfo *info)
>      return ti;
>  }
>  
> +/* HACK: util/module.c */
> +extern bool modules_init_done[MODULE_INIT_MAX];
> +static TypeImpl *type_get_by_name(const char *name);
> +
>  static TypeImpl *type_register_internal(const TypeInfo *info)
>  {
>      TypeImpl *ti;
>      ti = type_new(info);
>  
> +    if (modules_init_done[MODULE_INIT_QOM]) {
> +        if (ti->parent && !type_get_by_name(ti->parent)) {
> +            g_free(ti);

The function type_new() has some g_strdup() action. We would need a
type_delete() in order to clean those up properly if we are taking
this approach. In v3 I decided to check the info, and avoid instantiating
a ti so I don't have to clean it up.

> +            return NULL;
> +        }
> +    }
> +

This would change the postcondition of the type_register*() familiy
of functions. It effectively  makes type_register_*() a 'mayfail'
depending on a global state, which is
modules_init_done[MODULE_INIT_QOM].  It affects all modules. IMHO we should also update the documentation if we decide to move forward with this approach.

I will give this a spin later.

Please have a look at my v3 and let us decide how to move forward based
on that.

Regards,
Halil

[..]


      reply	other threads:[~2021-03-03 14:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-22 12:55 [PATCH v2 1/1] hw/s390x: modularize virtio-gpu-ccw Halil Pasic
2021-02-22 17:18 ` Boris Fiuczynski
2021-02-22 17:30   ` Daniel P. Berrangé
2021-02-23 12:14     ` Halil Pasic
2021-02-24 11:36 ` Gerd Hoffmann
2021-02-24 16:46   ` Halil Pasic
2021-02-25  8:05     ` Gerd Hoffmann
2021-02-25 21:14     ` Halil Pasic
2021-03-03  7:07       ` Gerd Hoffmann
2021-03-03 14:36         ` Halil Pasic [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=20210303153647.626d9aa6.pasic@linux.ibm.com \
    --to=pasic@linux.ibm.com \
    --cc=berrange@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=brogers@suse.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=fiuczy@linux.ibm.com \
    --cc=kraxel@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=thuth@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).