qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH 9/9] Introduce VLANClientState::cleanup()


From: Markus Armbruster
Subject: Re: [Qemu-devel] Re: [PATCH 9/9] Introduce VLANClientState::cleanup()
Date: Wed, 29 Apr 2009 09:36:59 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)

Anthony Liguori <address@hidden> writes:

> Paul Brook wrote:
>> On Thursday 16 April 2009, Mark McLoughlin wrote:
>>   
>>> However, the way I see it is that the VLANClientState should "own" the
>>> PCIDevice, not the other way around - e.g. you want to free the device,
>>> you should do qemu_del_vlan_client(), rather than
>>> pci_device_unregister().
>>>     
>>
>> I disagree. This makes it impossible to have multiport devices.
>> The controlling entity should be the device, not the vlan interface.
>>   
>
> I agree.  The biggest problem with the current API (and most QEMU
> APIs) is there's no way to associate host configuration with the
> function's devices implement.  Instead, host configurations are
> associated with actual devices which implies that all devices
> implement one function.  This is clearly wrong.
>
> For example, the way this all should work is (ignore the current VLAN
> concept in QEMU, it's orthogonal to this discussion):
>
> 1) Network backend is created.  As part of the configuration of the
> backend, a unique device identifier is associated with it.
> 2) A PCI device is created.
>  a) The PCI device creates one or more Network frontends.  Each
> frontend carries the device identifier and perhaps something like a
> port id.
>  b) When the PCI device is destroyed, it destroys any frontends it owns.
>
> The unique device identifier could be a device tree path, or it could
> be something more opaque that is later correlated to a device tree
> path.
>
> Regards,
>
> Anthony Liguori

The machine configuration patch is designed for such a separation.  A
target device can be connected to host artifacts.  The connection is a
tree node UID.  Currently the node address, but it could be anything; we
could use small integer handles or textual labels.

The initial implementation of a device is a simple wrapper around
existing device interfaces.  This is intentional.  It lets us convert to
the new device interface device by device.  Such a conversion involves
disentangling host and target part, putting the former in suitable host
artifacts, leaving the latter in the target device.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]