From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LyqSM-0001Gr-O1 for qemu-devel@nongnu.org; Tue, 28 Apr 2009 12:46:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LyqSH-0001Ca-UD for qemu-devel@nongnu.org; Tue, 28 Apr 2009 12:46:53 -0400 Received: from [199.232.76.173] (port=39200 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LyqSH-0001CO-FV for qemu-devel@nongnu.org; Tue, 28 Apr 2009 12:46:49 -0400 Received: from rv-out-0708.google.com ([209.85.198.242]:55673) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LyqSH-0002ib-23 for qemu-devel@nongnu.org; Tue, 28 Apr 2009 12:46:49 -0400 Received: by rv-out-0708.google.com with SMTP id c5so409767rvf.22 for ; Tue, 28 Apr 2009 09:46:48 -0700 (PDT) Message-ID: <49F732F4.6020708@codemonkey.ws> Date: Tue, 28 Apr 2009 11:46:44 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 9/9] Introduce VLANClientState::cleanup() References: <1239812969-8320-2-git-send-email-markmc@redhat.com> <20090416010725.GA24264@amt.cnet> <1239893397.6860.190.camel@blaa> <200904281308.26203.paul@codesourcery.com> In-Reply-To: <200904281308.26203.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Mark McLoughlin , Anthony Liguori , Marcelo Tosatti , qemu-devel@nongnu.org, Markus Armbruster 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 > 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. > > Paul > > >