From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EADD2C433DF for ; Wed, 15 Jul 2020 13:59:26 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AA02F20657 for ; Wed, 15 Jul 2020 13:59:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=vayavyalabs.com header.i=@vayavyalabs.com header.b="pfW8bOVB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AA02F20657 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=vayavyalabs.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:47564 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jvhwU-0003MK-03 for qemu-devel@archiver.kernel.org; Wed, 15 Jul 2020 09:59:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41712) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jvhvj-0002Pb-68 for qemu-devel@nongnu.org; Wed, 15 Jul 2020 09:58:39 -0400 Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]:50951) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jvhvh-00069D-3d for qemu-devel@nongnu.org; Wed, 15 Jul 2020 09:58:38 -0400 Received: by mail-wm1-x32f.google.com with SMTP id c80so5727403wme.0 for ; Wed, 15 Jul 2020 06:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vayavyalabs.com; s=vayavyalabs; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=71vsjZyKHeQHRcgMoFDwb+YhtVO3aOMvNMfDmXy70SI=; b=pfW8bOVBBDHI/lkS2PPTTmyWSl650cfLbCIyucOdoH6a2zFEnsyprNzQ9c0QxVInYX bMIV1QKDd7UVm/yJViFxERkQKhr89qBBGaCnIbGFk3wXV5lbn5unMDmmLKLAYioVXxes 25UukmUIddrIgnCOWTTGi8996i6klNiyanA1I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=71vsjZyKHeQHRcgMoFDwb+YhtVO3aOMvNMfDmXy70SI=; b=ZPtFdBwV6aJNzedtPm1PHftz30VPIoQ9z8lCwed3+zoyLiv5rgNDh9Q0nqTMQ5zT+M kDWYlneknjHynofOUYer9Q752ONz9UsUD+ONLoegTqG+FdRjWJJHueCmZKMTrffl2bfm Tv8LVBS9ApUAFtj0wx3pqiDOgcEAVMCVS/r790M1WhvgwAslRwEOZ4theoKs4aQmXJIV +zU2h7OezU3ENnjjAcKq4OfYSEkOktY2Z6GfpXFRlKJSK8kct04BdApXvxQmN8lTADrY 5tzbn8+eMDIjhy18DpMRV3SMPgR6SCtyhwP1RS+BbCg1lPUamexefTZfYsMX2mi424Pc 4pgQ== X-Gm-Message-State: AOAM533twvA0Hn4xpmiWMk+hLjW+4BfKIK1GvObx+B2LoprIgudZvcvL po+ERt8bC9Gd4dOXw6XY7No0gqrR4O2RlK53KN+6gA== X-Google-Smtp-Source: ABdhPJzrl+1WdsAn3T/pRmUVqAp/RDZ/NOUkvLU5DNjjNS4OHYO9/hV3NWCOhesWzWLWDQR+CNAbSgwLaboKOFECwOM= X-Received: by 2002:a1c:2485:: with SMTP id k127mr8580388wmk.138.1594821515412; Wed, 15 Jul 2020 06:58:35 -0700 (PDT) MIME-Version: 1.0 References: <87365t18mp.fsf@dusky.pond.sub.org> In-Reply-To: <87365t18mp.fsf@dusky.pond.sub.org> From: Pratik Parvati Date: Wed, 15 Jul 2020 19:28:24 +0530 Message-ID: Subject: Re: sysbus_create_simple Vs qdev_create To: Markus Armbruster Content-Type: multipart/alternative; boundary="000000000000e823d605aa7b5143" Received-SPF: pass client-ip=2a00:1450:4864:20::32f; envelope-from=pratikp@vayavyalabs.com; helo=mail-wm1-x32f.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --000000000000e823d605aa7b5143 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Markus and Philippe, Thanks for your reply. Now I am pretty clear about Qdev and sysbus helper function. Can you please explain to me in brief on buses and device hierarchies (i.e. BusState and DeviceState) and how they are related to each other? As I can see, the DeviceState class inherits the BusState struct DeviceState { /*< private >*/ Object parent_obj; /*< public >*/ const char *id; char *canonical_path; bool realized; bool pending_deleted_event; QemuOpts *opts; int hotplugged; bool allow_unplug_during_migration; BusState *parent_bus; \\ BusState is inherited here QLIST_HEAD(, NamedGPIOList) gpios; QLIST_HEAD(, BusState) child_bus; int num_child_bus; int instance_id_alias; int alias_required_for_version; ResettableState reset; }; and BusState, in turn, inherits the DeviceState as /** * BusState: * @hotplug_handler: link to a hotplug handler associated with bus. * @reset: ResettableState for the bus; handled by Resettable interface. */struct BusState { Object obj; DeviceState *parent; \\ DeviceState is inherited here char *name; HotplugHandler *hotplug_handler; int max_index; bool realized; int num_children; QTAILQ_HEAD(, BusChild) children; QLIST_ENTRY(BusState) sibling; ResettableState reset; }; I am a bit confused. Can you brief me this relation! Thanks and Regards, Pratik On Wed, Jul 15, 2020 at 2:02 PM Markus Armbruster wrote= : > Philippe Mathieu-Daud=C3=A9 writes: > > > Hi Pratik, > > > > On 7/14/20 6:17 PM, Pratik Parvati wrote: > >> Here is a brief context that might help you. > >> I am referring hw/arm/versatilepb.c > >> > >> The ARM PrimeCell UART (PL011) device created as follows > >> > >> dev =3D qdev_create(NULL, "pl011"); > >> s =3D SYS_BUS_DEVICE(dev); > >> qdev_prop_set_chr(dev, "chardev", chr); > >> qdev_init_nofail(dev); > >> sysbus_mmio_map(s, 0, addr); > >> sysbus_connect_irq(s, 0, irq); > > This is pl011_create(). > > Since recent merge commit 6675a653d2e, it's > > dev =3D qdev_new("pl011"); > s =3D SYS_BUS_DEVICE(dev); > qdev_prop_set_chr(dev, "chardev", chr); > sysbus_realize_and_unref(s, &error_fatal); > sysbus_mmio_map(s, 0, addr); > sysbus_connect_irq(s, 0, irq); > > >> > >> Whereas the PL031 RTC device is created as > >> > >> /* Add PL031 Real Time Clock. */ > >> sysbus_create_simple("pl031", 0x101e8000, pic[10]); > >> > >> What is the difference between these two devices creation? > > > > Both devices inherit SysBusDevice, which itself inherits QDev. > > Yes: TYPE_SYS_BUS_DEVICE is a subtype of TYPE_DEVICE. > > > You can create QDev objects with the qdev API, and > > SysBusDevice objects with the sysbus API. > > Yes. > > qdev_new(), qdev_realize_and_unref(), ... work with DeviceState * (the C > type of an instance of QOM TYPE_DEVICE). > > sysbus_realize_and_unref(), ... work with SysBusDevice * (the C type of > an instance of QOM TYPE_SYS_BUS_DEVICE). > > Since TYPE_SYS_BUS_DEVICE is a subtype of TYPE_DEVICE, you can safely > use qdev_ functions with sysbus devices. Example: pl011_create() uses > qdev_new() to create a sysbus device. That's fine. > > > sysbus_create_simple() is a condensed helper, but only allow you > > to pass qemu_irq objects, not a 'chardev' property. So for this > > case you have to use the qdev API instead. > > Yes. It's a helper that combines creating a sysbus device, wiring up > one MMIO region and one IRQ, and realizing. If you need to configure or > wire up more than that, you can't use it. > > >> How do I know > >> which method to use while creating an object? > > > > SysBusDevice are plugged onto a bus. QDev aren't. > > The sysbus API results in smaller code, easier to review. > > The general pattern for a stand-alone device is > > dev =3D qdev_new(type_name); > set properties and wire up stuff... > qdev_realize_and_unref(dev, bus, &err); > > When this is to be done in device code, say to create a component > device, the split between .instance_init() and .realize() complicates > things. If interested, ask and I'll explain. > > There are quite a few wrappers around qdev_ functions for various > subtypes of TYPE_DEVICE. Use them to make your code more concise and > easier to understand. Example: sysbus_realize_and_unref(). > > There are also convenience functions that capture special cases of the > entire general pattern. Example: sysbus_create_simple(). > > Hope this helps! > > --000000000000e823d605aa7b5143 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Markus and Philippe,

Thanks for your reply. Now I am= pretty clear about Qdev and sysbus helper function.

Can you please explain to me in= brief on buses and device hierarchies (i.e. BusState and DeviceState) and = how they are related to each other? As I can see, the DeviceState class inh= erits the BusState 

struct DeviceState {
    /*< private >*/
    Object parent_obj;
    /*< public >*/

    const char *id;
    char *canonical_path;
    bool realized;
    bool pending_deleted_event;
    QemuOpts *opts;
    int hotplugged;
    bool allow_unplug_during_migration;
    BusState *parent_bus; \\ BusState is inherited here
    QLIST_HEAD(, NamedGPIOList) gpios;
    QLIST_HEAD(, BusState) child_bus;
    int num_child_bus;
    int instance_id_alias;
    int alias_required_for_version;
    ResettableState reset;
};

and BusState, in turn, inherits= the DeviceState as 


/**
 * BusState:
 * @hotplug_handler: link to a hotplug handler associated with bus.
 * @reset: ResettableState for the bus; handled by Resettable interface.
 */
struct BusState {
    Object obj;
    DeviceState *parent; \\ DeviceState is inherited here
    char *name;
    HotplugHandler *hotplug_handler;
    int max_index;
    bool realized;
    int num_children;
    QTAILQ_HEAD(, BusChild) children;
    QLIST_ENTRY(BusState) sibling;
    ResettableState reset;
};

I am a bit confused. Can you br= ief me this relation!

Thanks and Regards,
Pratik

<= br>
On Wed,= Jul 15, 2020 at 2:02 PM Markus Armbruster <armbru@redhat.com> wrote:
Philippe Mathieu-Daud=C3=A9 <philmd@redhat.com> writes:

> Hi Pratik,
>
> On 7/14/20 6:17 PM, Pratik Parvati wrote:
>> Here is a brief context that might help you.
>> I am referring hw/arm/versatilepb.c
>>
>> The ARM PrimeCell UART (PL011) device created as follows
>>
>>=C2=A0 =C2=A0 =C2=A0dev =3D qdev_create(NULL, "pl011"); >>=C2=A0 =C2=A0 =C2=A0s =3D SYS_BUS_DEVICE(dev);
>>=C2=A0 =C2=A0 =C2=A0qdev_prop_set_chr(dev, "chardev", chr= );
>>=C2=A0 =C2=A0 =C2=A0qdev_init_nofail(dev);
>>=C2=A0 =C2=A0 =C2=A0sysbus_mmio_map(s, 0, addr);
>>=C2=A0 =C2=A0 =C2=A0sysbus_connect_irq(s, 0, irq);

This is pl011_create().

Since recent merge commit 6675a653d2e, it's

=C2=A0 =C2=A0 =C2=A0 =C2=A0dev =3D qdev_new("pl011");
=C2=A0 =C2=A0 =C2=A0 =C2=A0s =3D SYS_BUS_DEVICE(dev);
=C2=A0 =C2=A0 =C2=A0 =C2=A0qdev_prop_set_chr(dev, "chardev", chr)= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0sysbus_realize_and_unref(s, &error_fatal); =C2=A0 =C2=A0 =C2=A0 =C2=A0sysbus_mmio_map(s, 0, addr);
=C2=A0 =C2=A0 =C2=A0 =C2=A0sysbus_connect_irq(s, 0, irq);

>>
>> Whereas the PL031 RTC device is created as
>>
>>=C2=A0 =C2=A0 =C2=A0/* Add PL031 Real Time Clock. */
>>=C2=A0 =C2=A0 =C2=A0sysbus_create_simple("pl031", 0x101e8= 000, pic[10]);
>>
>> What is the difference between these two devices creation?
>
> Both devices inherit SysBusDevice, which itself inherits QDev.

Yes: TYPE_SYS_BUS_DEVICE is a subtype of TYPE_DEVICE.

> You can create QDev objects with the qdev API, and
> SysBusDevice objects with the sysbus API.

Yes.

qdev_new(), qdev_realize_and_unref(), ... work with DeviceState * (the C type of an instance of QOM TYPE_DEVICE).

sysbus_realize_and_unref(), ... work with SysBusDevice * (the C type of
an instance of QOM TYPE_SYS_BUS_DEVICE).

Since TYPE_SYS_BUS_DEVICE is a subtype of TYPE_DEVICE, you can safely
use qdev_ functions with sysbus devices.=C2=A0 Example: pl011_create() uses=
qdev_new() to create a sysbus device.=C2=A0 That's fine.

> sysbus_create_simple() is a condensed helper, but only allow you
> to pass qemu_irq objects, not a 'chardev' property. So for thi= s
> case you have to use the qdev API instead.

Yes.=C2=A0 It's a helper that combines creating a sysbus device, wiring= up
one MMIO region and one IRQ, and realizing.=C2=A0 If you need to configure = or
wire up more than that, you can't use it.

>> How do I know
>> which method to use while creating an object?
>
> SysBusDevice are plugged onto a bus. QDev aren't.
> The sysbus API results in smaller code, easier to review.

The general pattern for a stand-alone device is

=C2=A0 =C2=A0 dev =3D qdev_new(type_name);
=C2=A0 =C2=A0 set properties and wire up stuff...
=C2=A0 =C2=A0 qdev_realize_and_unref(dev, bus, &err);

When this is to be done in device code, say to create a component
device, the split between .instance_init() and .realize() complicates
things.=C2=A0 If interested, ask and I'll explain.

There are quite a few wrappers around qdev_ functions for various
subtypes of TYPE_DEVICE.=C2=A0 Use them to make your code more concise and<= br> easier to understand.=C2=A0 Example: sysbus_realize_and_unref().

There are also convenience functions that capture special cases of the
entire general pattern.=C2=A0 Example: sysbus_create_simple().

Hope this helps!

--000000000000e823d605aa7b5143--