[Top][All Lists]

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

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [PATCH 9/9] Introduce VLANClientState::cleanup()
Date: Tue, 28 Apr 2009 11:46:44 -0500
User-agent: Thunderbird (X11/20090320)

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

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.


Anthony Liguori

This is related to some of the issues I've raised with the machine config patches. IMO it's important to consider how this kind of internat interaction should actually work, rather than blindly implementing whatever we currently expose to the user.


reply via email to

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