Re: [Qemu-devel] [PATCH] qdev: Assign a default device ID when none is provided.

[Markus Armbruster]

Paolo Bonzini <address@hidden> writes:

> Il 09/01/2014 19:18, Hani Benhabiles ha scritto:
>> On Wed, Jan 08, 2014 at 06:34:01PM +0100, Paolo Bonzini wrote:
>>> Il 08/01/2014 18:17, Hani Benhabiles ha scritto:
>>>> For this reason, the loop in assign_device_name() specifically
>>>> check that the ID
>>>> doesn't exist already and uses the next value if it does.
>>>>
>>>> How would something like:
>>>> (qemu) device_add virtio-net-pci
>>>> ==> ID: virtio-net-pci.0
>>>>
>>>> Be more problematic than:
>>>> (qemu) device_add virtio-net-pci,id=virtio-net-pci.0
>>>
>>> (qemu) device_add virtio-net-pci
>>> (qemu) device_add virtio-net-pci,id=virtio-net-pci.0
>>>
>>> works without your patches, fails with them (IIUC).
>> 
>> It would fail with a clear and descriptive message (Duplicate ID) which is no
>> different than when a user uses tries to do so manually.
>
> It would still be a regression.
>
>> Without the patch, how does a user unplug a device for which he didn't 
>> specify
>> an ID (eg. forgotten, added quickly...)
>
> He doesn't. :)
>
>> It is even more confusing with other commands like info networks.
>> 
>> (qemu) device_add virtio-net-pci
>> (qemu) device_add virtio-net-pci,id=foo
>> (qemu) info network 
>> virtio-net-pci.0:
>> index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
>> foo: index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
>> (qemu) device_del foo
>> (qemu) device_del virtio-net-pci.0
>> Device 'virtio-net-pci.0' not found
>
> This could be considered a bug in "info network" too.  You might use a
> different template such as "unnamed virtio-net-pci #1" in net/net.c's
> assign_name.
>
> Paolo
>
>> If the naming scheme is an issue, could something like starting it with one 
>> or
>> two underscores better suited ?

In the design of qdev, the path in the qtree is the address that always
works, and IDs are abbreviations the user can define for his
convenience.  Unfortunately, we botched qtree paths so badly, they're
effectively unusable.  We consequently never made them available as
command arguments.  They only occur as values of the bus property, if I
remember correctly.

One possible recovery plan is to give up on paths, and auto-generate
IDs.

Another one is to ditch the unusable legacy qtree paths, and adopt the
"real" paths instead, namely the QOM paths.  I like this plan better.

Commands taking a device ID could be extended to take a path in the QOM
graph instead of an ID.

In the human monitor, it could perhaps work like this:

    IDs consist of letters, digits, '-', '.', '_', starting with a
    letter (see id_wellformed())
    
    If the argument doesn't contain '/', interpret it as ID.
    Else, if it starts with '/', interpret it as QOM path anchored at
    "the root" (which needs to be defined).
    Else, split it at the first '/', and interpret the prefix as ID, and
    the suffix as as QOM path anchored at whatever has that ID.

Requires means to inspect the QOM graph to be usable.