From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shreyansh Jain Subject: Re: [PATCH v8 2/9] test: add basic bus infrastructure tests Date: Wed, 18 Jan 2017 14:12:14 +0530 Message-ID: <8dd7ee97-b68f-0090-b128-cd693a314317@nxp.com> References: <1484647774-28984-1-git-send-email-shreyansh.jain@nxp.com> <2193672.0sRautH3mz@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Cc: To: Thomas Monjalon Return-path: Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0059.outbound.protection.outlook.com [104.47.41.59]) by dpdk.org (Postfix) with ESMTP id 469B758CD for ; Wed, 18 Jan 2017 09:38:51 +0100 (CET) In-Reply-To: <2193672.0sRautH3mz@xps13> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wednesday 18 January 2017 12:58 PM, Thomas Monjalon wrote: > 2017-01-18 06:56, Shreyansh Jain: >>>>> +/* Bus list exposed */ >>>>> +extern struct rte_bus_list rte_bus_list; >>>> >>>> I think it should be possible to write a test without the real list >>>> of registered bus. >>> >>> Yes, it is possible. I just modeled it on test_pci assuming that is a kind of >>> expected/standard. But, it seems probably it is not. I will change the tests. >> >> After sending out this mail I realized the real reason for using the actual lists. Functions like rte_eal_pci_register (for PCI) or rte_bus_register (for Bus), use global lists for registration. Test cases calls these functions for registering dummy device/bus. > > Why access to the bus list is externally required? > I feel there is something wrong here. It should be private in PCI. When I stated rte_eal_pci_register required global lists, I meant in previous code base (pre bus), the pci_device_list and pci_driver_list were public because registration function used them and test cases used the registration function. > >> One way is to not worry about adding these test/dummy devices/buses to original list as they would be unregistered anyway. But, risk is of impacting running list assuming multiple cases need to be run from same application/binary context. >> >> Another way is to rewrite these functions locally in test case, but that also means not testing these global registration/de-registration functions. >> >> Former method would continue to have symbols exported. Later is not testing some entry/exit functions of a sub-system. >> >> You still interested in this change? > > I would prefer you do not lose time with testing at this stage. > Ok. I will leave it as it is for now.