All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>
Cc: libvir-list@redhat.com, "Jiri Denemark" <jdenemar@redhat.com>,
	"Peter Krempa" <pkrempa@redhat.com>,
	qemu-devel@nongnu.org, "Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
Date: Fri, 02 May 2014 16:54:00 +0200	[thread overview]
Message-ID: <5363B188.9090500@redhat.com> (raw)
In-Reply-To: <20140502144305.GJ3363@otherpad.lan.raisama.net>

Il 02/05/2014 16:43, Eduardo Habkost ha scritto:
> The first thing I considered was making icc-bus user-creatable. Then I
> noticed it wouldn't work because object-add always add objects to
> /objects, not inside the qdev hierarchy (that's where device_add looks
> for the bus).
>
> So, allowing device_add could be possible, but would require changing
> more basic infrastructure: either allowing bus-less devices on
> device_add, or allowing device_add to add devices outside the qdev
> hierarchy, or allowing object-add to create objects outside /objects.
>
> Simply making CPU objects work with object-add was much simpler and less
> intrusive. And it had the interesting side-effect of _not_ doing things
> that are not required for CPU model probing (like creating an actual
> VCPU thread).

I like this series in general.  I have only some doubts about making the 
code somewhat future-proof, hence the three questions I have are really 
variations of this same doubt:

* is it worthwhile to extend this to other devices, for management to 
query default values of the properties?

* how does this interact with future QOMification of device hotplug 
where devices will be hotplugged with object-add?  Should 
Device::UserCreatable::complete set realized to true in this case in the 
future?  How will Device::UserCreatable::complete distinguish the two cases?

* Related to this, if Device::UserCreatable::complete will set realized 
to true, how will we handle hotplug of interconnected devices where 
device 1 needs a link to device 2 and device 2 needs a link to device 1?

Paolo

  reply	other threads:[~2014-05-02 14:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1398889773-14652-1-git-send-email-ehabkost@redhat.com>
2014-05-02 13:45 ` [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing Igor Mammedov
2014-05-02 14:43   ` Eduardo Habkost
2014-05-02 14:54     ` Paolo Bonzini [this message]
2014-05-02 16:43       ` Eduardo Habkost
2014-05-06  7:22     ` Igor Mammedov
2014-05-06 14:42       ` Eduardo Habkost
2014-05-06 20:01         ` Igor Mammedov
2014-05-06 20:19           ` Eduardo Habkost
2014-05-06 20:29             ` Andreas Färber
2014-05-08 18:29               ` Eduardo Habkost
2014-05-15 12:35               ` Igor Mammedov
2014-05-15 13:07                 ` Eduardo Habkost
2014-05-15 13:09                   ` Andreas Färber
2014-05-15 13:48                   ` Igor Mammedov
2014-05-15 14:03                     ` Eduardo Habkost
2014-05-16 14:52                       ` Igor Mammedov
2014-05-16 15:16                         ` Eduardo Habkost
2014-05-16 14:57                 ` Andreas Färber
2014-05-06 22:13             ` [Qemu-devel] [libvirt] " Eric Blake
2014-05-15 12:14             ` [Qemu-devel] " Igor Mammedov
2014-05-15 13:35               ` Eduardo Habkost
     [not found] ` <1398889773-14652-2-git-send-email-ehabkost@redhat.com>
2014-05-15 12:28   ` [Qemu-devel] [RFC 1/5] cpu: Initialize cpu->stopped=true earlier Igor Mammedov

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=5363B188.9090500@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=afaerber@suse.de \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=jdenemar@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=pkrempa@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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.