All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	qemu-devel@nongnu.org, "Stefan Hajnoczi" <stefanha@redhat.com>,
	patches@linaro.org
Subject: Re: [Qemu-devel] [PATCH 1/2] hw/sysbus.h: New sysbus_init_child() helper function
Date: Tue, 20 Feb 2018 14:23:19 +0100	[thread overview]
Message-ID: <20180220142319.2c959f83@redhat.com> (raw)
In-Reply-To: <2d4874be-fec4-39bb-9df5-bb53f17d1d74@redhat.com>

On Tue, 20 Feb 2018 13:13:49 +0100
Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 16/02/2018 18:40, Philippe Mathieu-Daudé wrote:
> > we can keep object_initialize() when no parent,
> > and add object_initialize_child(, const char *childname, Object *parent)
> > 'parent' last because all previous args are child-related.
> >   
> >>  
> >>> +    qdev_set_parent_bus(DEVICE(child), sysbus_get_default());  
> >> and then assuming we don't create sysbus devices, nor should be able to,
> >> which are not attached to sysbus_get_default() this one can go sysbus' instance_init()  
> > good idea.
> >   
[...]

> I'm not sure about moving qdev_set_parent_bus to instance_init().  It
> would be a bit different from other buses and possibly confusing.
That's what this series sort of does, i.e. creating a type/class
specific helper(s). Which becomes confusing as number of helpers
increases (frankly it's just 2 different approaches to code i.e.
functional vs OOM).

It could be better to keep single QOM API and let SYSBUS base class
instance_init() to do all implicit initialization that must be done
for inherited classes.
Yes, it will be different from other devices with buses but
users won't really care (there is no other buss to assign to),
for them it will look like a typical bus-less device and it
would be less error-prone to code.

 
> Potentially there could be a "hierarchy" of *_initialize_child
> functions, adding or removing arguments as needed for the specific kind
> of bus:
> 
> 	/* adds qdev_set_parent_bus */
> 	device_initialize_child(Object *parent, const char *childname,
> 				BusState *bus, void *data, size_t size,
> 				const char *typename);
> 	/* uses sysbus_get_default() */
> 	sysbus_initialize_child(Object *parent, const char *childname,
> 				void *data, size_t size,
> 				const char *typename);


> 	/* initializes "addr" property too */
> 	pci_initialize_child(Object *parent, const char *childname,
> 			     BusState *bus, int addr,
> 			     void *data, size_t size,
> 			     const char *typename);
PCI could also incorporate PCI specific bus setting/
verification logic inside of base class.

It could allow us to drop bus assigning magic in qdev_device_add(),
bringing it closer to simple QOM object handling, with specifics
abstracted by respective TYPE implementations.
Maybe we would be able to unify -device with -object in the end.


> Thanks,
> 
> Paolo
> qdev_device_add

  reply	other threads:[~2018-02-20 13:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-16 13:45 [Qemu-devel] [PATCH 0/2] Reduce QOM boilerplate with sysbus_init_child() helper Peter Maydell
2018-02-16 13:45 ` [Qemu-devel] [PATCH 1/2] hw/sysbus.h: New sysbus_init_child() helper function Peter Maydell
2018-02-16 16:28   ` Igor Mammedov
2018-02-16 17:40     ` Philippe Mathieu-Daudé
2018-02-20 12:13       ` Paolo Bonzini
2018-02-20 13:23         ` Igor Mammedov [this message]
2018-03-24 15:35           ` Philippe Mathieu-Daudé
2018-03-26 12:41             ` Igor Mammedov
2018-02-16 13:45 ` [Qemu-devel] [PATCH 2/2] hw/arm/bcm2835_peripherals: Use sysbus_init_child() Peter Maydell

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=20180220142319.2c959f83@redhat.com \
    --to=imammedo@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=patches@linaro.org \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --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 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.