All of lore.kernel.org
 help / color / mirror / Atom feed
From: Like Xu <like.xu@linux.intel.com>
To: Eduardo Habkost <ehabkost@redhat.com>,
	Markus Armbruster <armbru@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Thomas Huth <thuth@redhat.com>,
	 qemu-trivial@nongnu.org, qemu-devel@nongnu.org,
	like.xu@intel.com, Igor Mammedov <imammedo@redhat.com>
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH v3 2/2] core/qdev: refactor qdev_get_machine() with type assertion
Date: Tue, 23 Apr 2019 15:59:31 +0800	[thread overview]
Message-ID: <3fc39df9-9c4e-219c-e7dc-c93754fd1315@linux.intel.com> (raw)
In-Reply-To: <20190417171059.GC25134@habkost.net>

On 2019/4/18 1:10, Eduardo Habkost wrote:
> On Wed, Apr 17, 2019 at 07:14:10AM +0200, Markus Armbruster wrote:
>> Eduardo Habkost <ehabkost@redhat.com> writes:
>>
>>> On Mon, Apr 15, 2019 at 03:59:45PM +0800, Like Xu wrote:
>>>> To avoid the misuse of qdev_get_machine() if machine hasn't been created yet,
>>>> this patch uses qdev_get_machine_uncheck() for obj-common (share with user-only
>>>> mode) and adds type assertion to qdev_get_machine() in system-emulation mode.
>>>>
>>>> Suggested-by: Igor Mammedov <imammedo@redhat.com>
>>>> Signed-off-by: Like Xu <like.xu@linux.intel.com>
>>>
>>> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
>>>
>>> I'm queueing the series on machine-next, thanks!
>>
>> Hold your horses, please.
>>
>> I dislike the name qdev_get_machine_uncheck().  I could live with
>> qdev_get_machine_unchecked().
>>
>> However, I doubt this is the right approach.
>>
>> The issue at hand is undisciplined creation of QOM object /machine.
>>
>> This patch adds an asseertion "undisciplined creation of /machine didn't
>> create crap", but only in some places.
>>
>> I think we should never create /machine as (surprising!) side effect of
>> qdev_get_machine().  Create it explicitly instead, and have
>> qdev_get_machine() use object_resolve_path("/machine", NULL) to get it.
>> Look ma, no side effects.
> 
> OK, I'm dropping this one while we discuss it.
> 
> I really miss a good explanation why qdev_get_machine_unchecked()
> needs to exist.  When exactly do we want /machine to exist but
> not be TYPE_MACHINE?  Why?

AFAICT, there is no such "/machine" that is not of type TYPE_MACHINE.

The original qdev_get_machine() would always return a "/container" 
object in user-only mode and there is none TYPE_MACHINE object.

In system emulation mode, it returns the same "/container" object at the 
beginning, until we initialize and add a TYPE_MACHINE object to the 
"/container" as a child and it would return OBJECT(current_machine)
for later usages.

The starting point is to avoid using the legacy qdev_get_machine()
in system emulation mode when we haven't added the "/machine" object.
As a result, we introduced type checking assertions to avoid premature 
invocations.

In this proposal, the qdev_get_machine_unchecked() is only used
in user-only mode, part of which shares with system emulation mode
(such as device_set_realized, cpu_common_realizefn). The new 
qdev_get_machine() is only used in system emulation mode and type 
checking assertion does reduce the irrational use of this function (if 
any in the future).

We all agree to use this qdev_get_machine() as little as possible
and this patch could make future clean up work easier.

> 
> Once the expectations and use cases are explained, we can choose
> a better name for qdev_get_machine_unchecked() and document it
> properly.
> 



WARNING: multiple messages have this Message-ID (diff)
From: Like Xu <like.xu@linux.intel.com>
To: Eduardo Habkost <ehabkost@redhat.com>,
	Markus Armbruster <armbru@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Thomas Huth <thuth@redhat.com>,
	qemu-trivial@nongnu.org, qemu-devel@nongnu.org,
	like.xu@intel.com, Igor Mammedov <imammedo@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 2/2] core/qdev: refactor qdev_get_machine() with type assertion
Date: Tue, 23 Apr 2019 15:59:31 +0800	[thread overview]
Message-ID: <3fc39df9-9c4e-219c-e7dc-c93754fd1315@linux.intel.com> (raw)
In-Reply-To: <20190417171059.GC25134@habkost.net>

On 2019/4/18 1:10, Eduardo Habkost wrote:
> On Wed, Apr 17, 2019 at 07:14:10AM +0200, Markus Armbruster wrote:
>> Eduardo Habkost <ehabkost@redhat.com> writes:
>>
>>> On Mon, Apr 15, 2019 at 03:59:45PM +0800, Like Xu wrote:
>>>> To avoid the misuse of qdev_get_machine() if machine hasn't been created yet,
>>>> this patch uses qdev_get_machine_uncheck() for obj-common (share with user-only
>>>> mode) and adds type assertion to qdev_get_machine() in system-emulation mode.
>>>>
>>>> Suggested-by: Igor Mammedov <imammedo@redhat.com>
>>>> Signed-off-by: Like Xu <like.xu@linux.intel.com>
>>>
>>> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
>>>
>>> I'm queueing the series on machine-next, thanks!
>>
>> Hold your horses, please.
>>
>> I dislike the name qdev_get_machine_uncheck().  I could live with
>> qdev_get_machine_unchecked().
>>
>> However, I doubt this is the right approach.
>>
>> The issue at hand is undisciplined creation of QOM object /machine.
>>
>> This patch adds an asseertion "undisciplined creation of /machine didn't
>> create crap", but only in some places.
>>
>> I think we should never create /machine as (surprising!) side effect of
>> qdev_get_machine().  Create it explicitly instead, and have
>> qdev_get_machine() use object_resolve_path("/machine", NULL) to get it.
>> Look ma, no side effects.
> 
> OK, I'm dropping this one while we discuss it.
> 
> I really miss a good explanation why qdev_get_machine_unchecked()
> needs to exist.  When exactly do we want /machine to exist but
> not be TYPE_MACHINE?  Why?

AFAICT, there is no such "/machine" that is not of type TYPE_MACHINE.

The original qdev_get_machine() would always return a "/container" 
object in user-only mode and there is none TYPE_MACHINE object.

In system emulation mode, it returns the same "/container" object at the 
beginning, until we initialize and add a TYPE_MACHINE object to the 
"/container" as a child and it would return OBJECT(current_machine)
for later usages.

The starting point is to avoid using the legacy qdev_get_machine()
in system emulation mode when we haven't added the "/machine" object.
As a result, we introduced type checking assertions to avoid premature 
invocations.

In this proposal, the qdev_get_machine_unchecked() is only used
in user-only mode, part of which shares with system emulation mode
(such as device_set_realized, cpu_common_realizefn). The new 
qdev_get_machine() is only used in system emulation mode and type 
checking assertion does reduce the irrational use of this function (if 
any in the future).

We all agree to use this qdev_get_machine() as little as possible
and this patch could make future clean up work easier.

> 
> Once the expectations and use cases are explained, we can choose
> a better name for qdev_get_machine_unchecked() and document it
> properly.
> 

  reply	other threads:[~2019-04-23  7:59 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-15  7:59 [Qemu-trivial] [Qemu-devel] [PATCH v3 0/2] vl.c: make current_machine as non-global variable Like Xu
2019-04-15  7:59 ` Like Xu
2019-04-15  7:59 ` Like Xu
2019-04-15  7:59 ` [Qemu-trivial] [Qemu-devel] [PATCH v3 1/2] vl.c: refactor " Like Xu
2019-04-15  7:59   ` Like Xu
2019-04-15  7:59   ` Like Xu
2019-04-16 21:16   ` [Qemu-trivial] " Eduardo Habkost
2019-04-16 21:16     ` Eduardo Habkost
2019-04-16 21:16     ` Eduardo Habkost
2019-04-17  5:26   ` [Qemu-trivial] " Markus Armbruster
2019-04-17  5:26     ` Markus Armbruster
2019-04-17  5:26     ` Markus Armbruster
2019-04-17 17:05     ` [Qemu-trivial] " Eduardo Habkost
2019-04-17 17:05       ` Eduardo Habkost
2019-04-17 17:05       ` Eduardo Habkost
2019-04-15  7:59 ` [Qemu-trivial] [Qemu-devel] [PATCH v3 2/2] core/qdev: refactor qdev_get_machine() with type assertion Like Xu
2019-04-15  7:59   ` Like Xu
2019-04-15  7:59   ` Like Xu
2019-04-16 21:20   ` [Qemu-trivial] " Eduardo Habkost
2019-04-16 21:20     ` Eduardo Habkost
2019-04-16 21:20     ` Eduardo Habkost
2019-04-17  5:14     ` [Qemu-trivial] " Markus Armbruster
2019-04-17  5:14       ` Markus Armbruster
2019-04-17  5:14       ` Markus Armbruster
2019-04-17 17:10       ` [Qemu-trivial] " Eduardo Habkost
2019-04-17 17:10         ` Eduardo Habkost
2019-04-17 17:10         ` Eduardo Habkost
2019-04-23  7:59         ` Like Xu [this message]
2019-04-23  7:59           ` Like Xu
2019-04-24 17:21           ` [Qemu-trivial] " Eduardo Habkost
2019-04-24 17:21             ` Eduardo Habkost
2019-04-24 17:21             ` Eduardo Habkost
2019-04-25  3:12             ` [Qemu-trivial] " Like Xu
2019-04-25  3:12               ` Like Xu
2019-04-25 17:48               ` [Qemu-trivial] " Eduardo Habkost
2019-04-25 17:48                 ` Eduardo Habkost
2019-05-06 11:17                 ` [Qemu-trivial] " Markus Armbruster
2019-05-06 11:17                   ` Markus Armbruster
2019-05-06 11:15           ` [Qemu-trivial] " Markus Armbruster
2019-05-06 11:15             ` Markus Armbruster

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=3fc39df9-9c4e-219c-e7dc-c93754fd1315@linux.intel.com \
    --to=like.xu@linux.intel.com \
    --cc=armbru@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=like.xu@intel.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@nongnu.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 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.