From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0061.outbound.protection.outlook.com [104.47.34.61]) by dpdk.org (Postfix) with ESMTP id 0968B1E2F for ; Mon, 9 Jan 2017 07:20:44 +0100 (CET) Received: from BY2PR03CA068.namprd03.prod.outlook.com (10.141.249.41) by DM5PR03MB2476.namprd03.prod.outlook.com (10.168.233.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.829.7; Mon, 9 Jan 2017 06:20:42 +0000 Received: from BY2FFO11FD029.protection.gbl (2a01:111:f400:7c0c::140) by BY2PR03CA068.outlook.office365.com (2a01:111:e400:2c5d::41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.829.7 via Frontend Transport; Mon, 9 Jan 2017 06:20:42 +0000 Authentication-Results: spf=fail (sender IP is 192.88.158.2) 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.158.2 as permitted sender) receiver=protection.outlook.com; client-ip=192.88.158.2; helo=az84smr01.freescale.net; Received: from az84smr01.freescale.net (192.88.158.2) by BY2FFO11FD029.mail.protection.outlook.com (10.1.14.212) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.803.8 via Frontend Transport; Mon, 9 Jan 2017 06:20:41 +0000 Received: from [10.232.14.87] ([10.232.14.87]) by az84smr01.freescale.net (8.14.3/8.14.0) with ESMTP id v096KcwZ028030; Sun, 8 Jan 2017 23:20:39 -0700 To: Thomas Monjalon References: <1482756644-13726-1-git-send-email-shreyansh.jain@nxp.com> <12579803.ZHBMo4GdSA@xps13> <105987546.PAaz77144n@xps13> CC: , From: Shreyansh Jain Message-ID: Date: Mon, 9 Jan 2017 11:54:10 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <105987546.PAaz77144n@xps13> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Matching-Connectors: 131284164414933477; (91ab9b29-cfa4-454e-5278-08d120cd25b8); () X-Forefront-Antispam-Report: CIP:192.88.158.2; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(7916002)(336005)(39860400002)(39450400003)(39380400002)(39850400002)(39840400002)(39410400002)(39400400002)(2980300002)(1110001)(1109001)(339900001)(189002)(377454003)(199003)(24454002)(377424004)(57704003)(76104003)(6306002)(33646002)(305945005)(69596002)(77096006)(83506001)(23746002)(93886004)(92566002)(50466002)(38730400001)(6916009)(2950100002)(68736007)(356003)(8676002)(229853002)(54906002)(6666003)(110136003)(8936002)(4326007)(85426001)(76176999)(54356999)(2906002)(81156014)(81166006)(50986999)(561944003)(5660300001)(105606002)(15395725005)(189998001)(31696002)(626004)(86362001)(230700001)(65826007)(4001350100001)(4001150100001)(36756003)(97736004)(104016004)(31686004)(64126003)(47776003)(65956001)(65806001)(106466001)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR03MB2476; H:az84smr01.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD029; 1:pRaUbFM3IZXLhKMZcWPZ/3a3nFq5i91yJeVpmqh0r8pxJy5Y3RPa7GmfjlCXB13yF4ugZdiHpIRr3Xiri+6z5gDLeWFwGlpdUQ6kt6xnCApggVvhPtFgDY0jjSHmd+MK25AlusjyfN3vfqEMZVQF2VHBqN/4nGUUEPua49xsvRAsQGYSPd7RBhloSyJTFfNrlMlqVPd9mDl0a5jxEMB1FULNtemlaG3q4ExQCWS2LwWZP2RFCvZPIMbKDtbEDvwePApfSYobYOWnRubnNgkHJCV9W6tz/ck1qwTZcO2Y5uyiu6YW1e5oRCF8pPtkMu8YG/u89c/vWAq+aXV4O8uuTq2sQVcTFNxalpa/OCkSgCw8K5hsKLs+wtt/B0nWn+ZDvZ+kFi83gmHMBRzLVc6vZTiT1xQ4hhNeN+Genqji4PG/aAZJ+0BrHg7xaEA8675M/6/kEqaw1XdzGqrHMLsxlfQaIGxQY8pVGcIF0TbOKvnpxx2jslyYWuEBFN20Lw3youvzX0QhcFHIbIHJo4awI8aYptVDiI8m8E5kY00j61mMTk5EEiTn6YbzEInKQsPK X-MS-Office365-Filtering-Correlation-Id: f9c60f68-ad38-4d70-09e5-08d43857a30d X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR03MB2476; X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2476; 3:vTTBN+jeddRK2MaXYHoGh3UADZrhgrax5i6CbeJZVLQVbqUZUX6ItwcCxvvRNg33tUSMA32G4NGgqKjBeSE3jAfCXOXZOaToZyJqKFiz+NfLJcFjqgjUCqN58Oi40thm5la/GIX1ewvXGOk3RQYK7fDedyWuSlaBZOO24yJP6pUJDWcQ36JgfSukgmYSQNunlbg3mw8u4qZT7VYtX4yWs0TGKcJbMPupxXsSySE/BGPHk0rcLW37JMCwCatZ4ji4JCsOii+9ZrlrMOmBs0jB0dZL5BipRMxAfwwQNh+K0T+tOK6E5GO+Oo0NizJFTO2O4pX6veO+ZzErSvom7xZ7PcKFtZPYsIpInf3D+2pSj2CjLPCQS/47eLXceUNuktvp X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2476; 25:m8ZtrZFjSBZH/V71icdOF1D4dBbSr55PF3EFakTnrnWajGByzo+moFRhbtSPtgnGHf0fgUB/ztHgsInedCf74ZcZgvIJa2n+cCpV2hVPSDXh9KX+fTZiktBBWjQJTCBPCBwNeYtK86eLUgKLbIwzgx1wmlkDn0sTrFrBLwedzYfFRMKOIn5eNf8T/1OJezA12k0O/pd2UBY/Dxjf6fLOuGcMNaS7P4ejiTm52lWn9KUaWohIYqs8q87tI6D0wklpuP1OfMosDqwgBx7Cah8wK2PuOR6+v6PgfNe5FRVVyaYShNlDJoMM3zUcEHbdWnW/MEPLnjvs1Ey3kGpXX9HDTI1uw6ABlF325mI1IkqC95/aAyVRpSjNHZwsQ5M1cMOuFDH/eqQGttL7YVUeAk8zHPGius0n0chWttrS+9vaF4x9Vjmp8vyGDz4k0p9fqMvOJBKXX3pciUls0/92XxW5DDPk355L7SOmBo8YcIWzCUEQzIFqlwCdTttRVO1F3OgqYCFn2ql0FjvcuTaD6YpD7Kji47dbrkufKX30+tThSoYIWQ2Kq7Q69GpPB3VNDMyA8M45pCulOr+sD4yft7Kesp+ovv0qY+19seG9eltf2MhzpWMnqoh/LbpAtZEsnYvceeZTmOD4DgzO8bwrokQHFvMoMh9k4xJlAlzM9eT9MlXeV420mQe/a9MC5iiwAr6UDIhr1yT5KyyG4L3mQQjuNEti543bGumt5QbPHRHHKXeGjbBWRre6M89UBcPtLV3PdwX27z6XztdwZcdx8D3uZ/1w0/shgypLL8kf/7PwNDIRiDUaFdG2pvqPKz7SKB3RGmibqhFHPmGu0WpRm9d4ar2fMLguXvcaQ5wE+O137vg= X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2476; 31:awUmV8HlVwqS6ExhUx6cNx730dmjagNWoNhZIHIGkooDmujFhGDlJ+omaciIpMwi9T+gbXzDFvQj/1MGVwKyTLS8MYxJEbWegxeErcRCxJxTf59iWUl5JbFkWCoMh0XFjzwGdhIqfJnCuKFLsBPJCDV1r0ztYgT7PULeY0HiiC4Y91CjFlvwpIgqECtBZRNw/mvAQ31aYuPHGJLgPAMIRQzc9uxW4iWeJ2CiHMKZuaHLMsx38b0DEhNERd+QBy8MYmF1H29aKKbvjtjeRFVTVQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6095060)(601004)(2401047)(13023025)(13017025)(13015025)(13024025)(13018025)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6096035)(20161123561025)(20161123559025)(20161123556025)(20161123563025)(20161123565025); SRVR:DM5PR03MB2476; BCL:0; PCL:0; RULEID:(400006); SRVR:DM5PR03MB2476; X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2476; 4:rY4mYxD1loiaA1Fiy+R1ObSJ/CyHgs6hmWshC1Qifr10JTnOH98RRESN2gXK432Acyx6ZP67+iKE78xCMpZhBvX+hHNLQI86KKmYExEQy9eCio8C/oypD//NTBxiyOf+pyGH4B97oylj9yQRAVr9ZpuBaNjDoK4AbDyUTWywNojSIwEUeS2qPxKprvCqRK02Ry/gSVHoWXKydjZviuAQwhqrumtWqNFrUWdQDLl32gpT3J0jFhV7sMWFvf9i+p+4NrohHCgbkyDSIEDaIyoIEOAtt6Tv0x11iyA/oMrSsUYY+rg8pqgtDSEvfAd9KrK8WeZ2FvdPVS+1qYZFFDzSRO0C/6/rscQ2OVfiIIddqpO3Y1dLIcQNX2ZWuL0XcJW6VUMMwngY36Sx6fr64grbcPM3IiA49s4/ZilHb6MZoHlSz6W3p5Sma6IEE3nUAWRbMq0B39t/JIlBV758ZQeq+AFZuqVdZrXJ6RSub5EdG6Gmgq3wW/z7/aTH5DOSG+mOqSfB3Eq4So3JgCtEMYPgzothWu0FHHMtZ+Pl/OIDDojeRGTXpxLIkL6G84eie43NI05+PzoOqrEepNIS5yBgZ6vd5WcO7lvc5Z2QMkJ6O1pbHggwDYTwRaEb0SrpZi4iPXpVnXiHDgu/idBeQAOgwVgaAA5o2AqtDZExZNB+maq0H1EkcR+Y6tucZCQFj2kRtPuIRwh9MCdWGQqhIGqLSw== X-Forefront-PRVS: 0182DBBB05 X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DM5PR03MB2476; 23:i3Wpj4MtTmXvpNY/bKhl2ZT4dKlZNM+tK11oN?= =?Windows-1252?Q?8Z+rtjivEycvAcYkZc+uuKEklbtjwybCtgfncX3Ci3gIKMKKZtR3FkB/?= =?Windows-1252?Q?s4+RKYM1HVSVfXUi+KdyRZNKL1WAtfXzMiUP/URzhHVpw8Iw9h/oc+h/?= =?Windows-1252?Q?J1uWSAJFcRWJfeBmu0AxSatvjQhXUsYLnoin+4d/Iaznsmh5eQz+rZjY?= =?Windows-1252?Q?/p/gjEa3w0xZKRMPljHR6BV0K8tf3GUtFTyPwnwwGGFMblIZXJT11u+u?= =?Windows-1252?Q?lbvbBMR7WYI9Q7lA48zs1JPARntthGr3UKoqnNzeLOrhuj3xCLdAIuo7?= =?Windows-1252?Q?TI+7HwsrFiHS2sHo0ESrhwmrgTc6opqo3yJpih9yjgoe3j6fr+G7tuFd?= =?Windows-1252?Q?KLce4Ksho3UgLI6kjx8QzMO3fvp/4H161g92Bt/AZdncjFg4tm9b9WCM?= =?Windows-1252?Q?RUyj7OF+nzFOpzzguAHFK2djkmI3qO594knKu4Uk2lomgwmTrXdXfY5o?= =?Windows-1252?Q?RZS7mYFYAKuL5MSw2CevJld3kVfriYuxY2ur5yErkuRbVjFjToSs8Kas?= =?Windows-1252?Q?pV6hQ6uVQgsCRsKk8xV1WESKYWSg9z/eLmlSG/5PlblxyjGI4P5YHMpo?= =?Windows-1252?Q?qRyfJ5GP+uEkOPdOgtx2tn4Ls+KLXsuG6gXFcXgEW9HRcQEi6bBvgzHJ?= =?Windows-1252?Q?KP1aBg9eJ/EMe8QHOF6RfHbEjGIkagRDlwxIuPj3rtfbbVl6hZxHg+ev?= =?Windows-1252?Q?OhwEiXRwJSzAUK3VuelT6J6J8ZPOVA6LA77tHoxMsCOK+DQ/ZiFkcwAV?= =?Windows-1252?Q?t5ah+as3Cr/qvXKg17weC5Xquoo+4C7wygc2nuyatKP2SjJHN38eJ3IL?= =?Windows-1252?Q?Lcc7LLvPf+AWajoa3aAneEdbg3vGhJnmFjD//jzXtZYdiFkBkH6B7MF6?= =?Windows-1252?Q?wdi9nMD2WOVoBX9JPoyJXMWQhV4LwoJOaIkbLI2n5wMSBawku9q3AGrI?= =?Windows-1252?Q?UrYW2QT16fia0KuTj7OwQZF3YPyp6JSKlmlC3T89VLiOvolnvUEcXUbK?= =?Windows-1252?Q?Fp14nbe3SVRfiTIOj6nJ8wRaPcPGwrWsXjMCguGglfPtXozSz4jYk4XF?= =?Windows-1252?Q?0fCmODu3hmgHLrNL/BjIAPIjqLi0TJ60MugWfg3akHWBHE/hHjbs7VWE?= =?Windows-1252?Q?zYVof4t85TSzIROjFHwOloQr1lBMDFXA7WXZuy21Om4cfZu4Sy1a3ilc?= =?Windows-1252?Q?ckTYEYd24ECFbEoc2Imf4egR2kNVuaVwJ1xRwDDNLk92tqUIDmtT2Tl2?= =?Windows-1252?Q?cFqWIgbOu8j2xE5Urwj/EVZys6RkV3KD6bRC8FaZgELtwQpE0pByWS+i?= =?Windows-1252?Q?M8fGnaZAjEyoFJ42MGGo3ZMYqcyVQI8IPV0NfuxB/IyokGntg/Pdye2G?= =?Windows-1252?Q?Odq5VfvHmEZOfQl9Cad+08+tYSmXEqJ17/JrN5yPmp3aVyePVp3DCi9h?= =?Windows-1252?Q?OXQWykH1WPyipOjU1kRxJffPlrWRcS14EdGPOqe5OuXXG5tFahyiocm+?= =?Windows-1252?Q?MbHDFZOO9KC3rq2bWRsFd7zq0h7Pqn70+chHWL1MF8PxJIiLGgpBXk7F?= =?Windows-1252?Q?k2Xf87JYsMAtREOQOscLjIS2+vf5Yvo3mSNCxQm03zBXVrVk/8xBM7XO?= =?Windows-1252?Q?Ea6fxSTrkTbttNLpMgtyDVWJHBpsJu8OgNbhSgUKtibAORlJCJ/dDhkZ?= =?Windows-1252?Q?TslXw5snlG5Yipzsc3r15Cw9zeAggJZ9myGWfB30WLCEenaq1yplwEV5?= =?Windows-1252?Q?r8jofbD/vutxjv3hRKiYreLMsLcEq/pRW1KXI+3GOZgNg4CfyHrY+M0E?= =?Windows-1252?Q?g4KbKaAHsJM?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2476; 6:YKlovZSEtA2545u03nckotRKSq8FNVxBNqzkRgCuUKCFPhh2T+Cp1+8VLpWvVg8f3pt7/1PRDUJhcrL3tEKfZWMce74q24kNvWg+s8h4cBXm0quckw/fa+Qt2Uh3nCzTcKc99wRmsOnvr/U9Q81b8adOS71+HV8NyGCelalUfPVgFRxxE3p7Oc0vZwpdUuD6uqKJTqhZqrFOy8eClvNZIiHMJCRXA6Z5wCb4cMcSLSJNnQBvm0KITjPQ6OrEIOGBo0Bmg9JQNzs63GREhyfotT2bbLeEL5viyI3n56PsdsH5Wz3Pwp7DvDfJLbD0rVauqGVi6ukiNabOMkALRte/AyiATD17v1IzMetWjNrl7lzt/t0Yh83BLurGb0+sM67OFFy5pZqa0p6X59mX1IYUtvvEkiu4QPyjZ91nYjXt8pnIzs1laPAXLHyiGy8jffKi; 5:1PWDTmP4zN5den+XyqVs+QckVoSc4ISVqrBNCQIWvA/EqBYzOTovTSfkdRZ9YZAFQx20+f/DjdoPTh40b+uP3rDpHIvAps3PLhnidpxgUzK+BhENgOnNLO19NbynZjgWRHVBH5Rwzx7h64CV+j3Zi7VYbQpUPgT6w+DSv09a9mXtEtQgEYqTTuP0fa3/zCu7; 24:9neKezJrRmoiWPLfMC0+DLHp8sL8Qnm6jPq5muMWmIlqITtWB1+sfWGcOaoiAwHJUig85ZwRrq8nvJ6NXX5qnT/LB0zB0jFGA71EFFaEU5Q= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM5PR03MB2476; 7:l6v0l4VaONkMWk+/VWzrtKJi+PCOowaxDkUXj4t09V10qYXW6wthNq9JtDlLQ1payNY7sGf+XMQJzyy/utjwz53zHffTBcb+y8yb+g/V5GlOy9RE8I84FalbP6gVkHIZLILkUjXZB/sjGdn2MjQ2OTvW100A4jEUzqKG/+n0wWypz157/whVjRhWmNGTXztdyz9sx25tLpAVwUhA6LOV8ZMAgLBetHBV+qG7Z0S8ENKIdlRmLlPwwI9+SHYhGYf6Hgpj9oyMWQLaNOKTCCFv+XKMa4vYCLuy76xkA1PcfP6HelcPy/te5RXiIT/X3IacSJQmod8QY8F/w19WiKXZ0WZlY69A/awnAQs9NDR03l+/sZCeu8GUHezE43mIFNe/70evj4nCoAH92Y+2PilJhHfZikxLyTwyM74uqRrRXhotLv+S6DaOz2aRH1aL+hHsvbiPfg6LTt4ijtbEJom+WA== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2017 06:20:41.2281 (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.158.2]; Helo=[az84smr01.freescale.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR03MB2476 Subject: Re: [dpdk-dev] [PATCH v5 01/12] eal/bus: introduce bus abstraction 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: Mon, 09 Jan 2017 06:20:45 -0000 On Friday 06 January 2017 08:25 PM, Thomas Monjalon wrote: > 2017-01-06 16:01, Shreyansh Jain: >> On Wednesday 04 January 2017 03:22 AM, Thomas Monjalon wrote: >>> 2016-12-26 18:53, Shreyansh Jain: >>>> +/** >>>> + * A structure describing a generic bus. >>>> + */ >>>> +struct rte_bus { >>>> + TAILQ_ENTRY(rte_bus) next; /**< Next bus object in linked list */ >>>> + struct rte_driver_list driver_list; >>>> + /**< List of all drivers on bus */ >>>> + struct rte_device_list device_list; >>>> + /**< List of all devices on bus */ >>>> + const char *name; /**< Name of the bus */ >>>> +}; >>> >>> I am not convinced we should link a generic bus to drivers and devices. >>> What do you think of having rte_pci_bus being a rte_bus and linking >>> with rte_pci_device and rte_pci_driver lists? >> >> This is different from what I had in mind. >> You are saying: >> >> Class: rte_bus >> `-> No object instantiated for this class >> Class: rte_pci_bus inheriting rte_bus >> `-> object instantiated for this class. >> >> Here, rte_bus is being treated as an abstract class which is only >> inherited and rte_pci_bus is the base class which is instantiated. >> >> And I was thinking: >> >> Class: rte_bus >> `-> Object: pci_bus (defined in */eal/eal_pci.c) >> >> Here, rte_bus is that base class which is instantiated. >> >> I agree that what you are suggesting is inline with current model: >> rte_device -> abstract class (no one instantiates it) >> `-> rte_pci_device -> Base class which inherits rte_device and >> is instantiated. > > Yes > >> When I choose not to create rte_pci_bus, it was because I didn't want >> another indirection in form of rte_bus->rte_pci_bus->object. >> There were no 'non-generic' bus functions which were only applicable for >> rte_pci_bus. Eventually, rte_pci_bus ended up being a direct inheritance >> of rte_bus. >> >>> I'm thinking to something like that: >>> >>> struct rte_bus { >>> TAILQ_ENTRY(rte_bus) next; >>> const char *name; >>> rte_bus_scan_t scan; >>> rte_bus_match_t match; >>> }; >>> struct rte_pci_bus { >>> struct rte_bus bus; >>> struct rte_pci_driver_list pci_drivers; >>> struct rte_pci_device_list pci_devices; >>> }; >> >> if we go by rte_bus->rte_pci_bus->(instance of rte_pci_bus), above is >> fine. Though, I am in favor of rte_bus->(instance of rte_bus for PCI) >> because I don't see any 'non-generic' information in rte_pci_bus which >> can't be put in rte_bus. > > The lists of drivers and devices are specific to the bus. > Your proposal was to list them as generic rte_driver/rte_device and > cast them. I'm just saying we can directly declare them with the right type, > e.g. rte_pci_driver/rte_pci_device. Ok. I get your point. Already changing the code to reflect this. > > In the same logic, the functions probe/remove are specifics for the bus and > should be declared in rte_pci_driver instead of the generic rte_driver. Yes, I agree with this after above argument. > > >>>> +/** Helper for Bus registration. The constructor has higher priority than >>>> + * PMD constructors >>>> + */ >>>> +#define RTE_REGISTER_BUS(nm, bus) \ >>>> +static void __attribute__((constructor(101), used)) businitfn_ ##nm(void) \ >>>> +{\ >>>> + (bus).name = RTE_STR(nm);\ >>>> + rte_eal_bus_register(&bus); \ >>>> +} >>> >>> By removing the lists from rte_bus as suggested above, do you still need >>> a priority for this constructor? >> >> I think yes. >> Even if we have rte_pci_bus as a class, object of rte_bus should be part >> of Bus list *before* registration of a driver (because, driver >> registration searches for bus by name). >> >> (This is assuming that no global PCI/VDEV/XXX bus object is created >> which is directly used within all PCI specific bus operations). >> >> There was another suggestion on list which was to check for existence of >> bus _within_ each driver registration and create/instantiate an object >> in case no bus is registered. I didn't like the approach so I didn't use >> it. From David [1], and me [2] >> >> [1] http://dpdk.org/ml/archives/dev/2016-December/051689.html >> [2] http://dpdk.org/ml/archives/dev/2016-December/051698.html > > OK, we can keep your approach of prioritize bus registrations. > If we see an issue later, we could switch to a bus registration done > when a first driver is registered on the bus. Thanks for confirmation. > > >>>> struct rte_device { >>>> TAILQ_ENTRY(rte_device) next; /**< Next device */ >>>> + struct rte_bus *bus; /**< Device connected to this bus */ >>>> const struct rte_driver *driver;/**< Associated driver */ >>>> int numa_node; /**< NUMA node connection */ >>>> struct rte_devargs *devargs; /**< Device user arguments */ >>>> @@ -148,6 +149,7 @@ void rte_eal_device_remove(struct rte_device *dev); >>>> */ >>>> struct rte_driver { >>>> TAILQ_ENTRY(rte_driver) next; /**< Next in list. */ >>>> + struct rte_bus *bus; /**< Bus serviced by this driver */ >>>> const char *name; /**< Driver name. */ >>>> const char *alias; /**< Driver alias. */ >>>> }; >>> >>> Do we need to know the bus associated to a driver in rte_driver? >>> Bus and driver are already associated in rte_device. >> >> Two reasons: >> 1/ A driver should be associated with a bus so that if required, all bus >> can be directly extracted - even when probing has not been done. > > I do not understand this need. For example, Looping over all drivers for plugging them out. We need to know which bus a driver is on so that we can unplug the devices associated with the driver on that bus. > >> 2/ device->driver would only be updated after probe. device->driver->bus >> would not be valid in such cases, if required. > > We can update device->driver on match. Yes, we can. > > Please let's do not over-engineer if not needed. > In this case, I think we can skip rte_driver->bus. Hm, Ok. This was more of prospective step. We can avoid it without much impact. I will change the code. > > >> Overall, I don't have objections for rte_bus->rte_pci_bus=>object as >> compared to rte_bus=>PCI-object. But, I would still like to get a final >> confirmation of a more preferred way. >> >> Meanwhile, I will make changes to accommodate this change to save time >> in case rte_pci_bus class is final/preferred method. > > It looks more natural to me to avoid class casting and use specialized classes > when possible. So yes I prefer instantiating rte_pci_bus. > However, I could be wrong, and will consider any argument. Ok. I will go with your argument - mostly because I am OK either way and we can always come back if framework changes are stable. > > Thanks >