From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0068.outbound.protection.outlook.com [104.47.34.68]) by dpdk.org (Postfix) with ESMTP id 2728AB6D for ; Wed, 25 Jan 2017 12:30:56 +0100 (CET) Received: from BN3PR0301CA0007.namprd03.prod.outlook.com (10.160.180.145) by BY2PR0301MB0742.namprd03.prod.outlook.com (10.160.63.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Wed, 25 Jan 2017 11:30:55 +0000 Received: from BN1BFFO11FD016.protection.gbl (2a01:111:f400:7c10::1:129) by BN3PR0301CA0007.outlook.office365.com (2a01:111:e400:4000::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13 via Frontend Transport; Wed, 25 Jan 2017 11:30:55 +0000 Authentication-Results: spf=fail (sender IP is 192.88.168.50) smtp.mailfrom=nxp.com; intel.com; dkim=none (message not signed) header.d=none;intel.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 BN1BFFO11FD016.mail.protection.outlook.com (10.58.144.79) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.803.8 via Frontend Transport; Wed, 25 Jan 2017 11:30:54 +0000 Received: from [10.232.14.39] ([10.232.14.39]) by tx30smr01.am.freescale.net (8.14.3/8.14.0) with ESMTP id v0PBUokW025741; Wed, 25 Jan 2017 04:30:51 -0700 To: Ferruh Yigit References: CC: Thomas Monjalon , "dev@dpdk.org" , Hemant Agrawal From: Shreyansh Jain Message-ID: <9945ee7a-3770-3273-3dfc-9ef57e5fe618@nxp.com> Date: Wed, 25 Jan 2017 17:05:30 +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: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Matching-Connectors: 131298174544848443; (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)(336005)(39400400002)(39840400002)(39410400002)(39860400002)(39450400003)(39380400002)(39850400002)(2980300002)(1110001)(1109001)(339900001)(3190300001)(199003)(189002)(76104003)(377454003)(24454002)(189998001)(83506001)(65806001)(65956001)(230700001)(23746002)(50466002)(2906002)(33646002)(104016004)(54906002)(6306002)(64126003)(626004)(53936002)(97736004)(85426001)(47776003)(110136003)(8656002)(4001350100001)(92566002)(65826007)(4326007)(5660300001)(38730400001)(36756003)(2950100002)(105606002)(6916009)(50986999)(68736007)(8936002)(54356999)(76176999)(6666003)(86362001)(356003)(77096006)(31696002)(229853002)(31686004)(15395725005)(106466001)(81156014)(305945005)(8676002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR0301MB0742; H:tx30smr01.am.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD016; 1:HQUIv5d0YYjj+TfU8UIH5ZSl8RBlaaRqnh/llK1sKy7I22ZVCvjm+l6c0E1XDKGmzzgPp8qiIzcS74TXhAkh36CQxjkiLsUhgvPJX7gCcBCoAbX+k96dva0aJKgdcrh5UZMydVUCPggKRqQRRWg6jwIeDMYroPOffXUeZc3yr0UuU9+WpTGjjuSWZ6UwwsuIJdNvBATGbe5jbXMqrCh1yYPAJz4WRAm8NVHt5YrjsvKoPzicSqnLpc6OznXn3EM1bj5tiXLXaRHVPXHIZ5Gn6hct+vgcMbo/j+FfvjN64U8TFIp2/J8QGlLWaqEkIgb7oUNwyZ7EdDdQJYY6Dn4vQy3MKiRKOWZxTcgKIhjR08NecoaEx4oAHdZgrdktvwZ+6ZPC38JjpzcAWh1oaHNKpB2UpNgHuJ7jYONK9wnrxVZvXSLHYxFt9IUeN2Zkt4iXCrq5NhN1F7Rgcknmizlp1BVmEZK4XIsSd8851ML2NI7bmXq94o9iNsD16QrLtQ6wcxrG4KTVMDLC8xob6jj1ptrGv/BAEUWm9NPjaURfDmSTfX2w+2WgyiBt72tCoN0n5WHyOUe4p1kFceyLIeBD2gzlqMJZ5ZN94H/aJ3QuIlfPJNAd7sPE2C0D5Qf+HcXE X-MS-Office365-Filtering-Correlation-Id: 5089c19f-348e-47d8-c4bf-08d445159fdb X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BY2PR0301MB0742; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0301MB0742; 3:srYAgbaPjUbS76PcnGt/qP8j3cDOCPkJCRRiJ7s05rH0Kqc+Uyxkkh84YFo0pC0ooLbjsQ3PncNdNtqDP8xyc9vJxECpjSKJKmqKumutM8yswsvAGi8wz6ZWpMwfD33dKKh2/r6K4yjGyWS0UBxB97P7WJfeD7Ex3Sk5JHo7Sr+uf9b4B2fJAWt5C1lzWZKmBsAGhEiiYtGZ/vZiqbYM25GqqYgYOL4YAX1+7CGF6jT++iE2Lq+09FVYIu0AXiX5hO5MyrxWV8fkVQtv+osHq4kG+u9SWvtlk/bAOIetmmSrf7jxMRFcK5aFF2xswCAtlfvRxac/W/1pq7FKAQlubCM7y+CkoLMbWeUgeCvoSeOuqer40MrBF5Y5dBUhJ9qY; 25:QRj8bxq2hK0dR2VnqlLDjDKJH42eL7JAe4rkup0Lv1+mVhbPDymBLALP7JtufVPL8rsUOnn82iwCrpQCm0MHahdTovk7nzVSKGIpdMbcP3kDVo3kC68ADV+jXkthRCLirFvEXxI/xlarT6XLe65Xg/84VriRzmWbbWUBl9rFBPt4CxXmQTiMZ/hCSAx4LSeh+XFBlJ/UoYip7C9y3wUd0Q6l7aiuIOajztXlE5CKb53tqvD/RyQ9VcdOM2PDaXivWGbeyzEzs5TQQFUHpoqPYSrfkZhtYR+8r1CQAylhSlyCJ6CRUIpjnkV7vOF1dnknP7CQ9X4SeIjnIZtne1guyr0VkARjg5aNo7gnxEMCWGJpYCRXNz/x++V4Yk6mG6dnAqj7omUnqOw2LyFa4H2jwvvezhM18Su4J+k1ne06PN55c1Pasa3h2Nr1h6GlyNL7Xrpy+BFE2jFZb9qzL0orcg== X-Microsoft-Exchange-Diagnostics: 1; BY2PR0301MB0742; 31:Tn3tM+ac2B/6W5AdH/KRMM+Xd6BRL9/uDjHC6VCvWJ+yALdf86DynfUG5r1ZHDpx5XKnA86Rp10/0Y20jaSffmImljkUWN3WZnNnRHcA2KIqcYyWNF7BVcPtGdyBy5QV+4r7Q5ukOJmb8gjqgW6oY+vNSBsc6cVlB5Vf4JRj+XMqik6PLepg/1qKIEBQ/nmA13tpL0H+N1m2eAimh65jTTXPoCVdAVhWXEmTxiEpXmYO217BtiDnmCwqc8zRx3f3fDm2LYhwq6kdYVK6k8RhrA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(227817650892897); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6095060)(601004)(2401047)(5005006)(8121501046)(13015025)(13017025)(13024025)(13023025)(13018025)(10201501046)(3002001)(6055026)(6096035)(20161123565025)(20161123563025)(20161123561025)(20161123559025)(20161123556025); SRVR:BY2PR0301MB0742; BCL:0; PCL:0; RULEID:(400006); SRVR:BY2PR0301MB0742; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0301MB0742; 4:q9u2ug9cvpnrn1G+iGB3qP1My6lqk79bzl7S62bJAGEQnN7sLrQ8iIwUDsU3+lDWBpYGfzew+Hju+WNCWi2buVmkjUlOBbkiLarr7PSG4WNNwxwJa5buNRL0xcvhE3jM4n1iA/gtfXL8zH58UcMG3TIZANLGLtLEN5h3vB2fF3G6S0XJg5qi6Fzcx7KQ1eaVgdAbQ/WOv1LItllIuNpc4Tb+TK4TMoDSbS8LK6ZArw5e8Shxqx/vaEq4Svr0ZrVjuVHyJ2ABwB6LsFkAy790pU1Pztzq4OC8pOOttRQGpffJOuNm+5lqt/qW2UjvyVXw0qnNdTfYhBM9kjryEvRPPDi00cHP5bmwKD6Ys0ryq/nQs0BmZXkP6zxME2GkLBU5skHKoOCzZtjYjjmxynyZ/wFc0Z4MTddu7gHQBnwP8JsKwLAVnsSYqBGOxCBnVbCAyAZ34aFjQZ9v5KDaXNbHp6qLZWTczj6eVhGG/9AJJziYCJv5po2UDYcAjmQE17/89/QQdGtKcIOgMHxA4NLry7cMrQ8iTUFDh9WYkHULf5Q2BZmV0IHwgKBNeLPMhYQ7Db59wZgWkIrRGejny6nQz9Z88CdtCZYr/ozY9zWJzQSz/w2QZMy9m+qgCleZk4Xj9UYK8RMOxw+Nixr7ANpzvaJm3eXIfG7z+dz+qSbMTVRQ/3Pi9g6nx10QClw3DWPMPI3jdySJS2L8zYKK53yp6ReOHV9k4yBHY24800aqkEIyfGrZvJYbhsZTxn09Xjs4 X-Forefront-PRVS: 01986AE76B X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BY2PR0301MB0742; 23:ZXNQ37JSBgcz1ph2ziKAz9exHFNF7Imfcwx?= =?Windows-1252?Q?WWadE2ozYVcJGycnvZn4XohVtxcpIHBHBcf/9FYqqg9kdc/Dpih11FMS?= =?Windows-1252?Q?Y8RkXcFkct9jWenWLlxKTLpxjWrv83hxdqpd+sec3xQSjo/5mtuRzFw4?= =?Windows-1252?Q?6lmZ8Uiu3bermg3TefomVCWl0vI7Zxt0GBVv9YwT0li5G+3bqA8hhA66?= =?Windows-1252?Q?8ECUbkU8qTv28VH1ipBdT5D3eHcgvaHSV5de1+Xyoosfj6hJ8G89/2Bn?= =?Windows-1252?Q?lProOI904wgRAjtXIly6YDsqnC38EqEhEpltDH3skwepmEfa6GXjfggy?= =?Windows-1252?Q?uOCqJ6eqkCzf0YbzY8IdS1g//IwQpenHjjKBM5E3lhV9sCcdkzkK30HF?= =?Windows-1252?Q?MrnrhY3r1HzN5gYl0jkyZn2dzeiAM9NbbZs83illDi+OQF4KYXykhWe/?= =?Windows-1252?Q?/wz6h/H25YCcFG/uXvMeigkofhnhkUAbr54IRvbaeQQ8JBKVjKPDp1/P?= =?Windows-1252?Q?H8rAVh+kZ+/fdH7qkt+fXzW8G12bSqoO3eZJcPDOEqhthVB18AW1stkH?= =?Windows-1252?Q?TuMfo7sbQgaQwg0YyA7d0WDKo9fodL9VjjKuAHu9nJSpG/XMxknVv/Tv?= =?Windows-1252?Q?lRuSJMasEk+/SstUMVTVi/s342X92WeEFB6bzWu7twd+PBDz0Y0AMjOx?= =?Windows-1252?Q?jSwpJPgwS8ZcFWsLq4NwXnlFBQSb/mSdfOQkkG7Y0GdQyKZkhTVWjcEG?= =?Windows-1252?Q?bAVOZW0nltDONv2uHH9NsbD4YQQDLiiDe0Zw613qWzqdlcHtb13qi1Sh?= =?Windows-1252?Q?hQR6DscV9vFYnckGZLiO1YAIWGBSU6dZcpTbisrcOu7e84l+0piM4gIk?= =?Windows-1252?Q?VjcG5T+IfeMKlZNZZL8FviPDsSy2qayvbO/s+30aRoMX9z+0T0Mf+eJ7?= =?Windows-1252?Q?JURQijQDlFVzVMPjFsjTUINZwDGjHKBwtNSkZqnxqKeBtDnuZljCtyIw?= =?Windows-1252?Q?uWddrGmV39bMfvsIpV+VoNNDDm6sxfftY/D1e3L8VctT9enym9d7VKLF?= =?Windows-1252?Q?mOhvhtd7dcjlmiw6OzD42T6gxu6azvLDxPlCQGcNf2CCWDRWQD9XfXnd?= =?Windows-1252?Q?cVwT23zUCjTjjOTy6QCty3yOsCad9S0Cr6EY0OarRGRuUDedqlOutXWM?= =?Windows-1252?Q?cDQ3S5Va+OE+wDlc6VM+1odlY3j0D5JpdHYEoj7YAhmwgC83u2bx2CXG?= =?Windows-1252?Q?+kCg9UFkE6Y2QioDg3YcdZcDa6T+toaimZU61mXmjM++4F/QfNH1cDxn?= =?Windows-1252?Q?iBUlm64Jj/4HX2UtUFtybZmmqoUy1n1s4OrUYOxbe4rC6VzqPGt+pgxW?= =?Windows-1252?Q?sGpDCIW7XAp443JOsyXAP+HQO9QXmix9CsgJsOJyBS4+Ze0qwGcvi8WX?= =?Windows-1252?Q?IO9ffAMe6jo3Hvj0DxqYghd+7kr2w1wVIR65RBSnkdBB73QnbTaPiFXd?= =?Windows-1252?Q?wMQPoa78O/oKfTUJ2+slArTK5TCrFWehj4y++NZEaoMoKpSaDSct1pWG?= =?Windows-1252?Q?Y97QVyVlPr0P1rIgOlO94Q1Xgw/TnPm+N1XSvczRmcURMNfrFYTrDZaA?= =?Windows-1252?Q?FGu4D+xY3RH8YlrkT9tad9Y9yLe9cLiCLG6gi0o8FVCeE6uFullOU3h3?= =?Windows-1252?Q?Gk/1wWDMb1unjgi0YwT1VpRSqE5RfvG/7jSb8g0Je6Y7HgXyG1H2F3D2?= =?Windows-1252?Q?v8AA/I8Wql+8BDI2QEw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR0301MB0742; 6:koNyxM9v5a6fsPeiBiQU8EJwdooKNK99eYEl8K2Cix6eO6f0PLm4J4Vcz322ykU2C/toW6pah17jNpNuZnSm4udygMrRJJ2bav71BcyxAEtTj7mrsM/aiTfWnHBRyj84eFxK97vuyaASfMnVgnpcY56S5Qy5iGOuVydaN6/YEttYIWe1VhgSBkDfU/ZHM6yY3l+Bdv3Emcj5wTSm96nGpzwetgH5RBQ1whmmegmo7gER8M/dIYS8OVnKadLeqYrPelPPB6LOZ0vK5CZ+eY09MS+6BXBmO+eU3SXF9oGrl3oeHGXOmsRGMtGS2tEsqulL5cr4fSmDxMjt5bjeDP/xIEVZ8p+nm94yHbbAZV2xrFFRcYO7/KV3q7d1cmRLdtrlEbTol8NVlH3V9qQd95+zg64obwP+y595FLm15W/8n5V+mPJ4aLu9BXd5DVpTHTRq; 5:kWqnrKVpdbEonSszllOmuSkPm9OZcTSCTtqdJX6yTb0TOfWaV53FIRfwMjeVgqT307rK5VzgYtpuR0Fj34Nozona7G3bwxnf5GLk0zC6jPHmbxhNHAP/IL5UR9HpXcz5Fm3m6nd04vUQ5/USTEIDdAPEcQb6urFTE94fHmMhnFKMKitagEhv65DEO2Mvl/aL; 24:HLW3YJkecTuGh0UxomeDAdE9G2OEq58gKsxb4LcclAu50B4VouARc2kprtwXYXQHSSgU7+EqEutBhJq/QYzlOjO1ZE0oZlxso9kH3C9K4kk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY2PR0301MB0742; 7:Z81/kxOmcM2qC4ll14nSfkbZXsH5ywtK8NBltkBalIvHjzOYCxiT6Sc5ueC4eYTHaSKqiIF5/CxcdwEKw9QnHphVVGzJamV+X0UpKdifHfnBQOuA85Y292TlRwEYHx8RXftA7iibBCDkXF5FOQx+9dFUJXXTWNh9U05SpJFijbb6DXTS8BoJ1JumIIlNnI+lDGm5aBEfKrUx8IBF9EGwH7k3OIYQCq7jOt4/iPwibJaqFFx0Zxudvu8BVrF+i8UjpJHQ2nSWb/QFpVaUY6ni7wf8ulxfnHHLBEyyYop8cIdpjKNZfnqLYNdYFaIK+9t1CTW77gtztKPW3INvP1Olr3qnAB1RamI+LdnIcDgo435hh9TEUmSVqBs9z9QDjKjPUub6aa3S5vVxA3UdHFTd3cSFpuiTKMzW3BjOJxyrP+SzisSfJmpGdd36fZJHmcIy6KbucYc8Nw7RsGaIv12BMQ== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jan 2017 11:30:54.2976 (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: BY2PR0301MB0742 Subject: Re: [dpdk-dev] NXP DPAA2: Symbol renaming issue: Request for Suggestions 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, 25 Jan 2017 11:30:58 -0000 Hello Ferruh, On Tuesday 24 January 2017 09:54 PM, Ferruh Yigit wrote: > On 1/24/2017 2:39 PM, Shreyansh Jain wrote: >> Hello, >> >> We are facing a peculiar problem with respect to symbol namespace in DPDK. I >> think Ferruh and Thomas would have fair idea about it as they have already >> reviewed and commented on it. I was hoping to get some input to take it >> forward from here. >> >> Brief Intro to DPAA2 Architecture: >> >> This is brief about NXP's DPAA2 PMD to start with: >> (A lot more information is available at [1]) >> >> >> >> +-------------------------------+ >> | Application | >> +----.--------------------.-----+ >> | | >> +----'------+ +-----'-----+ >> drivers/---->| DPIO | | DPIO |<---drivers/bus/fslmc >> bus/fslmc +----.------+ +------.----+ >> | | >> +----/-||--------------||--/----+ >> | Queue/Buffer Manager |<--- drivers/common/dpaa2 >> +----\-||--------------||--\----+ qbman >> | | >> +----'------+ +------'----+ >> drivers/ --->| DPNI | | DPSEC |<---drivers/cyrpto >> net/dpaa2 +----|------+ +-----|-----+ dpaa2_sec >> | | >> +----|------+ +------|-----+ +----------------+ >> | PHY H/W | | SEC H/W | .> FSL MC BUS | >> +-----------+ +------------+ / +----------------+ >> drivers/bus/fslmc >> >> >> If we consider the above layout, drivers/crypto/dpaa_sec (NXP's DPAA2 Crypto >> PMD, already available on ML [2]), and drivers/net/dpaa2 (NXP's DPAA2 PMD) are >> using a common code (drivers/common/dpaa2/qbman). >> >> QBMAN (drivers/common/dpaa2/qbman) is essentially a Queue and Buffer Manager >> set of APIs which allow DPIO (Data Path IO interfaces) to communicate with the >> Hardware through queues (and buffers). >> >> At the scan time, FSLMC bus is scanned and all devices (Phy or Sec) are >> identified and added to a list. For each such device, appropriate I/O portals >> are opened which are essentially gateway between user-space and DP* devices >> using the hardware queues/buffers (qbman) >> >> Problem: >> >> You might have noticed that we have exposed a lot of symbols from >> drivers/common and drivers/bus for drivers/net and drivers/crypto. All these >> symbols are not rte_* as what has been suggested for exported symbols. >> >> Review comments have been received for renaming these to make them rte_* or >> _rte_* prefixed. >> >> Just as a side note, these symbols are being exposed _internally_ within >> drivers/* area. >> >> There are (3) possible solutions we have: > > What do you think about following: > > Create wrappers for DPDK with namespace, and export those for DPDK. > And in the user side, create macros to convert them back. > > sample: [1] > > Although this may work, I am not sure this really worth the effort, if > there is no intended consumer of these API other than dpaa2 code. > > > [1] > ====== > > API .c (no modification): > int func_foo() {}; > ------ > > wrapper.c (new file): > int rte_foo() { return func_foo(); } > ------ > > *version.map: > ... > rte_foo; > ... > ------ > > user dpdk_macro.h (new file): > #define func_foo rte_foo > .... > ------ > > user.c (no modification except include): > #include "dpdk_macro.h" > > func_foo(); > > ====== > I too considered this option (1/ below). But, this is an unclean approach. Adding wrappers around functions is going to performance impact considering that all the code in this library is datapath. Besides, it means we need to maintain our APIs across internal changes (though, API changes are not frequent, I agree). Another option being what Thomas suggested - to keep the library external to DPDK. That is better than this but would impact ease of use. (And I do remember some comments on ML about external libraries not being preferred.) But, thanks for your suggestion. I need to figure out something. > > >> >> 1/ Rename all the symbols: >> - This is a difficult option for us. Renaming means breaking our linkage >> with existing code (Linux Kernel upstream candidate as well as internal >> repository). >> - Changing it means maintaining this change set internally/independently >> which is not a feasible long term solution. >> >> 2/ Merge all the libraries together: >> - In the initial RFC days, there were review comments which suggested that >> we should break the PMD into common libraries and place it in drivers/* >> parallel folders. >> - This is precisely the reason we are facing the situation. >> - Another possibility is to start duplicating the code for common. But, this >> too has a technical limitation for us as some data structures are shared >> across net and crypto and it is not possible to have multiple instances of >> those. >> - One more offshoot option could have been to keep the library external >> of the DPDK framework (external location and linked on demand basis, >> manually). We don't prefer this as this will make it difficult for any user >> to use DPAA2 easily. >> >> 3/ Finding a way to keep symbols internal to drivers/* independent of rte_* >> prefix: >> - For example, allowing symbols to be exposed limited to drivers/* area >> and not allowing them to be available across lib/* (not sure how, though!) >> >> > can help us arrive to a solution?> >> >> My argument for this: >> - With new bus infra in place, there would be more drivers being contributed. >> It also means that there would be PMDs having their own code and symbol >> models. It would be difficult to ask all of them to mandatorily adhere >> to a naming scheme. >> This argument bodes well for lib/* because that is core (libraries) which >> should be controlled for uniformity and performance. >> >> [1] https://www.kernel.org/doc/readme/drivers-staging-fsl-mc-README.txt >> [2] http://dpdk.org/ml/archives/dev/2017-January/054251.html >> > >