From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46220) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ffsCJ-00086s-BS for qemu-devel@nongnu.org; Wed, 18 Jul 2018 15:33:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ffsCE-00018H-BX for qemu-devel@nongnu.org; Wed, 18 Jul 2018 15:33:15 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:33490) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ffsCE-00017z-4o for qemu-devel@nongnu.org; Wed, 18 Jul 2018 15:33:10 -0400 Received: by mail-wr1-f67.google.com with SMTP id g6-v6so5782350wrp.0 for ; Wed, 18 Jul 2018 12:33:09 -0700 (PDT) References: <20180709091136.28849-1-e.emanuelegiuseppe@gmail.com> <20180709091136.28849-3-e.emanuelegiuseppe@gmail.com> <20180711144920.GN31228@stefanha-x1.localdomain> <494e6b18-a5e9-0521-4ace-dca2160ea191@redhat.com> <20180718142927.GN21825@stefanha-x1.localdomain> <2d822611-d227-1e9e-bfb4-d119f78a0282@gmail.com> From: Paolo Bonzini Message-ID: <645dd61a-b309-4a54-3e59-2dce23244045@redhat.com> Date: Wed, 18 Jul 2018 21:33:06 +0200 MIME-Version: 1.0 In-Reply-To: <2d822611-d227-1e9e-bfb4-d119f78a0282@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/7] tests/qgraph: pci-pc driver and interface nodes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Emanuele , Stefan Hajnoczi Cc: Laurent Vivier , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org On 18/07/2018 20:29, Emanuele wrote: > I had to put this patch here because it also introduces > qpci_device_init, used by sdhci (patch 3). > > For the next version I plan to have a patch X where I rename all > occurrences of qpci_init_pc in qpci_pc_new, and a patch X+1 that > introduces qpci_init_pc (was qpci_set_pc) and the other changes. > > Should I only introduce qpci_device_init in patch 3 and the remaining > things in patch 5? > > I think the general problem here is that in some patches I create > functions that are planned to only be used only in next patches (of the > current series). I think it's okay this way, however you should justify the changes you make to "qgraph-ify" each component. For patch 1, let's wait for Stefan's reply. Because patch 1 is introducing the infrastructure, I think it is acceptable that some definitions are introduced early as long as they have doc comments; it would make little sense to introduce get_device in patch 4 just because there are no "contains" edges until then. However, introducing the qos-test directly at the beginning is also a possibility. In either case, we need better doc comments for the function pointers in QOSGraphObject. Paolo