From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0077.outbound.protection.outlook.com [104.47.32.77]) by dpdk.org (Postfix) with ESMTP id 8145D32A5 for ; Wed, 7 Dec 2016 14:07:37 +0100 (CET) Received: from BN3PR0301CA0057.namprd03.prod.outlook.com (10.160.152.153) by DM5PR03MB2474.namprd03.prod.outlook.com (10.168.233.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Wed, 7 Dec 2016 13:07:36 +0000 Received: from BY2FFO11OLC014.protection.gbl (2a01:111:f400:7c0c::160) by BN3PR0301CA0057.outlook.office365.com (2a01:111:e400:401e::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.9 via Frontend Transport; Wed, 7 Dec 2016 13:07:35 +0000 Authentication-Results: spf=fail (sender IP is 192.88.168.50) smtp.mailfrom=nxp.com; 6wind.com; dkim=none (message not signed) header.d=none;6wind.com; dmarc=fail action=none header.from=nxp.com; Received-SPF: Fail (protection.outlook.com: domain of nxp.com does not designate 192.88.168.50 as permitted sender) receiver=protection.outlook.com; client-ip=192.88.168.50; helo=tx30smr01.am.freescale.net; Received: from tx30smr01.am.freescale.net (192.88.168.50) by BY2FFO11OLC014.mail.protection.outlook.com (10.1.15.48) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.734.4 via Frontend Transport; Wed, 7 Dec 2016 13:07:35 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:; UpperCasedChecksum:; SizeAsReceived:1044; Count:13 Received: from [10.232.14.87] ([10.232.14.87]) by tx30smr01.am.freescale.net (8.14.3/8.14.0) with ESMTP id uB7D7VkD023616; Wed, 7 Dec 2016 06:07:32 -0700 To: David Marchand References: <1480846288-2517-1-git-send-email-shreyansh.jain@nxp.com> CC: "dev@dpdk.org" , Thomas Monjalon From: Shreyansh Jain Message-ID: <1697fe66-962d-0848-5e68-615249b52dad@nxp.com> Date: Wed, 7 Dec 2016 18:40:21 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-IncomingHeaderCount: 13 X-EOPAttributedMessage: 0 X-Matching-Connectors: 131255896554985301; (91ab9b29-cfa4-454e-5278-08d120cd25b8); () X-Forefront-Antispam-Report: CIP:192.88.168.50; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(7916002)(2980300002)(1109001)(1110001)(339900001)(336004)(199003)(189002)(377454003)(24454002)(39450400002)(81156014)(5660300001)(4001350100001)(33646002)(93886004)(39380400001)(6666003)(2906002)(230783001)(110136003)(65826007)(2950100002)(39400400001)(38730400001)(6916009)(47776003)(54356999)(50986999)(105606002)(68736007)(76176999)(189998001)(64126003)(65806001)(39410400001)(39840400001)(50466002)(8676002)(39850400001)(97736004)(39860400001)(65956001)(8936002)(36756003)(31686004)(92566002)(77096006)(81166006)(106466001)(229853002)(31696002)(104016004)(626004)(7846002)(305945005)(230700001)(4326007)(83506001)(356003)(23676002)(85426001)(86362001)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR03MB2474; H:tx30smr01.am.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11OLC014; 1:7Lkub/d+crH2gV0TTEghUoZI366aCZmfrfbOdBdGTVnTGUS39y1JSM6VmBwdUoL3YYUebRxxQFm0J3lZ1kWToCA6D36c4jeiNsgGdu+x3JnjsuC20ScvH5I8HSOia1+flgKKdfJa+EHq2MnX1oxSH45Rins9rrgFai8pQaQcJaWem22u863VetXg1rLgrSeGQzKJrM5wM5VvZHDszA38YxXsk7BmEbhSZwVF0EdqjoTsN9YX8eozULej7vOEeFsioQjp8nSRaksQmjklLR6PWl0p99wZkSyNiVyUufAFhR3jMgxyiW1nuL2PmXx5qu7I+KM6YOnca5jfsQd3NoNaTZBlNYtUbI6IWEFWZAVMpmj6/ynOZOvtCkfb+N3NNrPh5jTMkvj6fdfPMPRwa5po/wsYsyAzRzMHMcLWlG1iJbOwq4Php+utPWKU++Qoci7mVhgXg1hWTwtc/s3H0yltQr4/M5bXvS/mcomhWSSxO/Whu7zL96LjhMBZMuIja0pBpMuPQaRIs0LpkLSxgjWoFiF3THZitTgzuQhjpt0RZilMCjKjBryv7wxpwV71sIZv74ik3lsu12PTX3faZAwKcAXecm/ldiyim/5DUBgzlz0= X-MS-Office365-Filtering-Correlation-Id: c3d48421-139d-4342-d755-08d41ea2034c X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR03MB2474; X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2474; 3:+FD3s7+tloWS8jETSlBjSONdy0byDCq0zJX+nNMLki5n9yqspUCUlolqjD9Wsk0PlykjlZLHR/TBqUNQX5ZKgFvZ9929xeMKUjSQ7g419m/knl4j1hAcdMLFxUY9G3+ov7MpJDJmjciacwZVEmGNG//Z1nsSSQDNaZ9fQqAWDi3GL48TEAbzMnmjgqdGy2ICpIy7YpkB8kso8JYxIlkSx0ctqPZd714XDE3JVxExJuI5pZ9diV14+WpbFpdVqMpKpqI3VfSmk5McskAnj5UHjn1b1kffd8ijQLbEkrU9s+q5hoCvG8g2NjPYL39wPcDeVV3gIWnQnhcEC4MdqDwmlt8LqS4ROsL/yAk+AGqhbxna7KHZEiNK92A3N8QYYGIR; 25:10c1CrT5tmU8NnL28QgzAGRAtjEf0GiuAMXnu4DthYAFEAi2Qt9YnPEP4IBQlt6XG9damGvuSpNv25dECFvdqRFp1aIwVyY7MdfbNFwXSNdo0PqGkIe9b2cqIE0XP9/6SnOgBWZuAy413wO22pbjDatrYMLnnF2ArHS/Qpoax2NvkJ9OzObDnAk7bPzHLu3hm5hMVZ/HI4XswW3Znjz/dzzc4PU3dDUd4uQxVJHcnDfyFTJlDFKXlHrJPTAYs+yqWtuo63mv2N1Uy0JvxSg1HFBUlkdfNQa//EDg9m48swJxdCqB9j8Xq3F42dsyySRTwTlhpTF8HtBMz6+9MzbVssX/4LLIG5aYAF4C0EwtS/2wJXPAADm/BOluCV1bRpPMPoOGyYc5mnCv3VtKDNqJdD900g1Fjw7uuDrsbU5/qRvzs5VaVbwuMVHPaQVd0Y+9iDjjGQGVSnQWs12J9kG+tg== X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2474; 31:1yizE3ZbqaXuSn7hvyCzN7KHqTCGEg+9R0jKZeHMFgVOoGacTcrWWZavf+z5s2wIbfGH8XcWuC/aGmRo4ijDvSflZMJHVovUr0DznKMEYek1CcrHCCqIXnvpc80xowcoFCxawJDzxM29bnWgjudryPDcC1aXGhGLIDnt80FnOx2LP8oWCJWwYLwNTNVCIB5twYMVQ0s//f+ozV91gwGwwB0PmYNtj7EraXonoN4J9Igo37Q1W6RKrdh5N4dJxrv6vzCY0twyxBe3r61luuWUvgzttZ7s45yN8lN/YT1flMw= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(185117386973197); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6095060)(601004)(2401047)(13023025)(13024025)(13015025)(13017025)(13018025)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6096035)(20161123559025)(20161123561025)(20161123565025)(20161123556025)(20161123563025); SRVR:DM5PR03MB2474; BCL:0; PCL:0; RULEID:(400006); SRVR:DM5PR03MB2474; X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2474; 4:j2AkhU60sqH5pVYJql60CdtXKqypyyEJjujpsCuNk1R+7Ky2F6qEsoAcOABjiwRMl7dUtWlckURhtnkWohVY9NwXpgbWS8D03XYNKaP7CAyBQijdmM4Xpe1V2/WMGzo84mWTDLmJHZTH0IldHtgqzCB09cW6bJrgGOxiPXos4uyOTGtZ628Ras5e91BUDw9Gaz4sDxbbT15NrgMS42L/SL86vbQ9ExxYP+QElOAh86APJ7cmOS771tvNim45KSaLyGvFxEmh9zchLTJvA29yCVl9ILGEMXuUhHTGbfXy/SbRuY5M61QJGzMc2UftwUs2gIomerHpfBhiWXX/n4VmxoqowwkGehxIPKB7n87wg/bzMam9Ctm4qvWgh+DeWpUtC7DrXDUYyCHvbmmwK66YcG3VYY4gyIPgy9G37XqLLkgu4D3AO+yhSOifJWqZmTxaTcVVQV3yqxNlNf0+Yn5oKoAxKxCw3JjXu2dmO4IoX7WWnTYnITUJkhpSMd2QRMpchoohJEPb+6M/yvGkH20fW3HaSG4kRTxAF3fX9PATjRhV+tiOdiLndvit5WB2zm6hcsBYz60HzYg//xJYAjKRQblPLV8jVct0Ax2rLj7DC5lWMua5OPu74269s/+OSG+k49Yo79SzVV8aW8eZl1+3bhu4Fg3lltE8G6LVPmp4/a0YDO8UVMC7Nhj3H7+L6Yw3tJMjwwTmtB/Nrxie6Vh4N0HRWJqHKaNbi/6TLfCvo6WHzoLdLv4cnC8wT80HoJ/F X-Forefront-PRVS: 01494FA7F7 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTVQUjAzTUIyNDc0OzIzOkE4TE55YmdxV0RvMHhtNitWK21jZjZpL29F?= =?utf-8?B?SDRpOUxHanoxNzAvSENyMkRvWGVTejNDMUlpM2FCcCs3QWpaa2U3RG1FTHdU?= =?utf-8?B?TFFJaGxBQThNaVYxZWJQcVlwcGt6dENlb0RJVk9DTjNkc2lFamQxenFBUWdx?= =?utf-8?B?UFIxTDZ6bVJyMkdYOTQzRTBEbjhDZ2FNdmhoRkMrQTlFNnRlMlhMOTR4Q3NP?= =?utf-8?B?ZDhkZy9XdUxOU1VrS0d2Qi94QWRLSGozU3lIbkJZSzFyQmlEV0I2V04vT0Y2?= =?utf-8?B?QWlQS0ZqYlk2bzhPVXd4cytHYXRuYktkSnZWMHR5U1Z6OU9JU0syU2pDaStp?= =?utf-8?B?enErSmRMTG9YSE01a29tMW9zZ1NDenBFQVIzWUJlU1RNb0F5cWpxN25sWk1u?= =?utf-8?B?Wkh5LytRQ3l3ZlFGYzg0ZXQxaHdGTFhya0Y0bTh2cDliUkdVU2VKRENvL1lR?= =?utf-8?B?VTIxSHRya1doMDVBaGVKemJPNUsrTHNRc1JudzNuNkFham1jRXkxV2hUcmZw?= =?utf-8?B?TVhsTnVJckkzR3VlWWg0QXd2YlluRzBmUGNjTlJsL29zTkxmS2RkSGZIbklG?= =?utf-8?B?UHdLWVlhWTZoSzNRL01TWjZGWE5ldjQrV2lxdE52czRvbTd0V3ZrckxBVndG?= =?utf-8?B?Z3lSNFFHZ1A3ZzFLVzVCMW9QamViT016K3RDVUhLNjFTVUtkMHd6bWo1OUlX?= =?utf-8?B?WFBlTXFmR2FMcktDdzB0Q3hmRXVqWnREbzhPbEdoN1I4aWtYQVM1Nk4xZkRR?= =?utf-8?B?cFl4RzRaaHNIazNsS3ZEa3dTSU9MUHF6ZSt5UDF4aXpPdkp3bzBkN0l5ZDg3?= =?utf-8?B?SVBTa3dtVnBCYU5mM2U0WWxrSnE2cXFZL0YwZHBGMFRpWHphaEdGMWJnZ1V2?= =?utf-8?B?TmdNMTQ1dTlsQUVGRmVlZ0wrSUdNUmxrL085RmxZMFNZeWdFL1lOOCtnZHNp?= =?utf-8?B?THBTQVRGdTgxNG9VbVA2OWZzNUFMK0FtbmVtdmlqNnZCQmEzcjR6MlcwV2Nl?= =?utf-8?B?cVdCM1c1dCtGWmNjZUlFVDFReHkrL0tMcDBvN1IrTnowOTRMMTJVS3FRM016?= =?utf-8?B?Z3RjVHRhM3pjeURBNUdLdDRQOGp5aHJJZVBpQ2ZoeUNVanFUVUtRUUlDc2Mw?= =?utf-8?B?VEtnYmQ4OEV5S1cwUjdRUVZ2a3BNSHJtVGlmalMyYUg4bjA0eExSV0FJclk3?= =?utf-8?B?ZkZhS2FiSW5NTS9iTGoyOXR1Y3ZMRXM1ekE3WGtCWUNOY3ZJOFhQUmV4NXdT?= =?utf-8?B?Q3hiNnBCVGFJcWJIVEJyT1BwTGlmYlJ5bEJpTFV3Zi9jeHBUMU1zMHM0Mk1Z?= =?utf-8?B?SWdKeXFuRisrWWRLRHQyMjJjTWhVcXJjVU8yV212akIwbXJHVGVQcVU2WGps?= =?utf-8?B?eDd6b3VZZmJmWGh6a1hTODBTSWlBWEdmQTIvU1I2cE1NUnhVS01kTm9BSUYw?= =?utf-8?B?MDJ5Q2ZtNWFNcDJ3aVpnZnBzS2hRcWlYcWxpTEplRXZqbnZITkRKd1BLVzV2?= =?utf-8?B?eEs2U2g5c2l4ZzFGMTZRYmg5dDRSbTAyZzErYzRQdHE2UzJUcmlGUEk4emlj?= =?utf-8?B?QVFpUEM2aUF4cGp4YlFWUDhVRDRiajZreW5reXF1YmxZWHd5UGxFY2lHVnlm?= =?utf-8?B?dmhoRzFZUGRMYVUyd0tLdFlNTlFnbVkvOVY2aFBnU05hSXpYamZiNnFHV2xY?= =?utf-8?B?T3BaRkMrQ1ZQdGhVYnBIbjIwSkJMaUNtZ1ZDYmVMWmhwblBjZDIyUjlvQ3JL?= =?utf-8?B?eHY0VFhQeXZkUWJtYSs1QkpubGpCelp0YS9ES01MQzVNMlpMTWVRWnI2STZu?= =?utf-8?B?NnBRTmpVM1orQXdDSGR2VGJWa1pzRnFLbmtvdC9jUXk2ZGJiV2ZadkdZTnNm?= =?utf-8?B?KzR6VkQ5dk9kcHdQN0FSVkt4emZPbWRTcURsbHBqTzVSTnNybkkvUjNUQU1T?= =?utf-8?B?bWx0TlQ5Zm8xdFJhWnR4dy9iMU9JaTVYU0dKNWdlTWJ5YkFjTWI4QnJpTGRo?= =?utf-8?B?Mi9jaEpnUlc5SGVla1J1NnZIQ0tuL3NyS0prRVZncUpDMEx4UGpIZTdIaG9L?= =?utf-8?B?VEl2M2dxanVSakNLWGYzS3YrKzNraEdDb2xsbndEZ3VXeEFWTm9aNm5WVTA2?= =?utf-8?B?ckE9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2474; 6:JHI+2J8vW2HVdZtt3lGH69119dG3k/ILaz5Pu5Swgn1FxZwCOUX9p0cioXReOxey8RVrti15TtFWBR61Th/LyX0z/LbrGOcA7aA9hJRIg3JoW2Vwsva7Rx9YZnLETlbnB39kIdIq64kLeh+FvbH/RONlisWU9ft83FL3VhcdQ4sqovlHpFv8157S9u6Fts+BW7kPMtB0cLMx6kinKgXhabUEkk8Kj4+Zd9qGU12tsVCD0Srb2GtUqRadko6le96PADR3vzmthVzIbPeTzgBSSQAgH2Rft5Xin1l250D5tficS5BqVcOm0whCf55gG3JmRrRufyI8tDmPxf6suwZvqRDFk6WtLpmBl1rvlqlGTrlPfQTdajBV82KviFTbQbNL/S+VAP9CA829KUolC/CpXqyQwNhiQyYwLNHv793o2XU8mGOnLBPJx3K0+bAhp/7D; 5:AE8KDpOMztfa6xHFnrJT6jhVS9lKjB5BlDuLSZIpXvx9Cf0iZdH9bSZi/iJ9bcT0h8Xq4h9sS7B5qv1/vYsDkkuH1FrgWGxwErOp2stLix1AkdAzbR4HZMFmFu9e+pa1kTVlhX0NQtUqls3SyfgRaFoYVnjkFXh1E5JRRNVjJs9WAGlsUgCElOGlEnR7VJCl; 24:hcD9ayuYau/XT42ChYgweF4+7KutldDNHJ2vvzlJSaLl1uJVGAJjtvAV5dfo2FBOp+5nuhqGXhtck+2BHLkETwYTjqaslLP9sq6DX5CMiOA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2474; 7:LVykPZWSd0CcDapUwY1N04gRDwzdJL1ZQoLzZ2F+MeREdOZaliVGPxV9pKyNRswSvmHreEmH4YJfw/GDPpw0Zua9fZs1uq4fiWRBtj7yczifn9he89HX6EKFL94TumO+2hCkAXP3Az60nxWxFzup4iIpe4y8JFkWG9RvISmXpWSvqUbCny7LC7IHlsZlitI7fSjbQRX6VJ6emS0nh8wmOM0CnCIGIltroNz1rbYYAKp5TVijGnrXwmGM5/dIuCBl8+4J7d4uWb3y/VV9gJZucvJqGHn9IRt5KPNHUKPlpwyBZxHoZQ7sQljGDt9ZIMTL/2vKH6djYvdA69oP/52q0EcyrfVviK9uRCtjd4WfIESEvsh/nfcyncYlk93hnoEBRY2z+Nsg6bl5qM76heHOa5UpwuviMj+DSIaCq66BKJ1yLGoCUmQAgqpkBU2OThAs1SGtJmXY9geeQVOSzswVaQ== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2016 13:07:35.2489 (UTC) X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[192.88.168.50]; Helo=[tx30smr01.am.freescale.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR03MB2474 Subject: Re: [dpdk-dev] [PATCH 00/13] Introducing EAL Bus-Device-Driver Model X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 13:07:38 -0000 On Wednesday 07 December 2016 05:47 PM, David Marchand wrote: > Hello Shreyansh, > > On Wed, Dec 7, 2016 at 10:55 AM, Shreyansh Jain wrote: >> On Wednesday 07 December 2016 02:22 AM, David Marchand wrote: >>>> 0002~0003: Introducing the basic Bus model and associated test case >>>> 0005: Support insertion of device rather than addition to tail >>> >>> >>> Patch 2 and 5 could be squashed. >> >> >> I deliberately kept them separate. I intent to extend the Patch 5 for >> hotplugging. But, if I don't end up adding support for that in this series, >> I will merge these two. > > Fine. > > >>> The constructor priority stuff seems unneeded as long as we use >>> explicit reference to a global (or local, did not check) bus symbol >>> rather than a runtime lookup. >> >> >> I didn't understand your point here. >> IMO, constructor priority (or some other way to handle this) is important. I >> faced this issue while verifying it at my end when the drivers were getting >> registered before the bus. >> >> Can you elaborate more on '..use explicit reference to a global...'? > > The drivers register themselves to a bus using this bus specific api. > > For pci, this is rte_eal_pci_register(). > The pci_bus object must be moved to eal_common_pci.c (we can stil > internally expose for bsd / linux specific implementations). > Then, rte_eal_pci_register() can add the pci driver to the pci_bus > drivers list even if this pci_bus object is not registered yet to the > buses list. So, in eal_common_bus.c --->8--- struct rte_bus *global_ptr_to_pci_bus = NULL; struct rte_bus pci_bus = { ... }; rte_eal_pci_register() { if (global_ptr_to_pci_bus == NULL) rte_eal_bus_register(&pci_bus) else // continue as if PCI bus is registered } --->8--- so, no RTE_REGISTER_BUS()? If yes, then RTE_REGISTER_BUS() should also check for an existing registration for duplication. I was banking on a model where bus handlers (or bus drivers) are independent entities, just like PMDs. So, we have a bus XYZ without any drivers necessarily based on it. By making registration dependent on driver registration, it becomes implicit that buses don't exist without drivers. I am not in favor of this - or maybe I lack enough reason for this (about how it will make framework/PMD life better). > > And no constructor order issue ? > > >>> >>> >>>> 0004: Add scan and match callbacks for the Bus and updated test case >>> >>> >>> Why do you push back the bus object in the 'scan' method ? >>> This method is bus specific which means that the code "knows" the >>> object registered with the callback. >> >> >> This 'knows' is the grey area for me. >> The bus (for example, PCI) after scanning needs to call >> rte_eal_bus_add_device() to link the device in bus's device_list. >> >> Two options: >> 1. Have a global reference to "pci" bus (rte_bus) somewhere in eal_pci.c >> 2. Call rte_eal_get_bus() every time someone needs the reference. >> 3. C++ style, 'this->'. >> >> I have taken the 3rd path. It simplifies my code to not assume a handle as >> well as not allow for reference fetch calls every now and then. >> >> As a disadvantage: it means passing this as argument - and some cases >> maintaining it as __rte_unused. >> >> Taking (1) or (2) is not advantageous than this approach. > > 1) is the simplest one. > > When you write a pci_scan method and embed it in you pci_bus object, > but this pci_scan method still wonders which bus object it is supposed > to work on, this is a bit like Schizophrenia ;-). :) This now is linked to the above issue of constructor priority and having a global bus reference. I don't personally prefer it. I will still give this a serious thought, though. > > >>> Is is that you want to have a single scan method used by multiple buses ? >> >> >> Yes, but only as a use case. For example, platform devices are of various >> types - what if we have a south-bound bus over a platform bus. In which >> case, a hierarchical bus layout is possible. >> But, this is far-fetched idea for now. > > Well, if you have no usecase at the moment, let's keep it simple, please. > Ok. > >>> >>>> 0006: Integrate bus scan/match with EAL, without any effective >>>> driver >>> >>> >>> Hard to find a right balance in patch splittng, but patch 4 and 6 are >>> linked, I would squash them into one. >> >> >> Yes, it is hard and sometimes there is simply no strong rationale for >> splitting or merging. This is one of those cases. >> My idea was that one patch _only_ introduces Bus services (structures, >> functions etc) and another should enable the calls to it from EAL. >> In that sense, I still think 4 and 6 should remain separate, may be >> consecutive, though. > > Ok, will see in next version of the patchset. Is there anything specific that you are looking for in patchset v2? I was thinking of: 0. fixing BSD compilation issue reported by CI 1. improving the test_pci.c 2. hotplugging 3. trying to move PCI to drives/bus/pci/linux/* and resolving how drivers link to it, and how EAL resources like devargs are consumed. Anything else? > > >>> >>>> 0007: rte_pci_driver->probe replaced with rte_driver->probe >>> >>> >>> This patch is too big, please separate in two patches: eal changes >>> then ethdev/driver changes. >> >> >> I don't think that can be done. One change is incomplete without the other. >> >> Changes to all files are only for rte_pci_driver->probe to rte_driver->probe >> movement. EAL changes is to allow rte_eth_dev_pci_probe function after such >> a change as rte_driver->probe has different arguments as compared to >> rte_pci_driver->probe. The patches won't compile if I split. >> >> Am I missing something? >>> >>> Why do you push back the driver object in the 'probe' method ? (idem >>> rte_bus->scan). >> >> >> I am assuming you are referring to rte_driver->probe(). >> This is being done so that implementations (specific to drivers on a >> particular bus) can start extracting the rte_xxx_driver, if need be. >> >> For example, for e1000/em_ethdev.c, rte_driver->probe() have been set to >> rte_eth_dev_pci_probe() which requires rte_pci_driver to work with. In >> absence of the rte_driver object, this function cannot call >> rte_pci_driver->probe (for example) for driver specific operations. > > Sorry, I am thinking a step ahead with eth_driver out of the picture. > But once eth_driver disappears, I can see no reason to keep this > driver in the probe method (Schizophrenia again). When eth_driver disappears, i was thinking of accomodating the eth_dev_init into the rte_pci_driver->probe/init. But, this is still a nascent thought. I am yet to start working on eth_driver. > > >