From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 0AF24AD92 for ; Fri, 13 Feb 2015 08:27:24 +0100 (CET) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1D7RNvS003321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 13 Feb 2015 02:27:23 -0500 Received: from localhost.localdomain (vpn1-7-60.ams2.redhat.com [10.36.7.60]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1D7RLwu020794; Fri, 13 Feb 2015 02:27:22 -0500 Message-ID: <54DDA759.3060908@redhat.com> Date: Fri, 13 Feb 2015 09:27:21 +0200 From: Panu Matilainen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Thomas Monjalon , "Gonzalez Monroy, Sergio" References: <6ca22ee1257e34ee2b89f2fb354d6c382b8f3e29.1423644785.git.pmatilai@redhat.com> <54DB3C35.9000104@redhat.com> <91383E96CE459D47BCE92EFBF5CE73B004F4AC14@IRSMSX108.ger.corp.intel.com> <3129786.dHlkKq5arh@xps13> In-Reply-To: <3129786.dHlkKq5arh@xps13> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] mk: fix missing link of librte_vhost in shared, non-combined config X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 07:27:25 -0000 On 02/12/2015 05:44 PM, Thomas Monjalon wrote: > 2015-02-11 12:31, Gonzalez Monroy, Sergio: >> From: Panu Matilainen [mailto:pmatilai@redhat.com] >>> On 02/11/2015 12:51 PM, Gonzalez Monroy, Sergio wrote: >>>> I think that vhost is being linked in the wrong place (plugins section). >>>> The plugins only get linked when building static libraries. >>>> I think the patch should also remove vhost from the plugins section. >>> >>> Right, so vhost isn't a pluggable driver in the sense that pmds are. I wont >>> claim to be familiar with all this virt-related puzzle pieces :) I'll send an >>> updated patch, I was just looking to fix build in my particular config and >>> ignored the rest. >>> >>> On a related note, shouldn't librte_pmd_bond and librte_pmd_xenvirt be >>> included in the plugins section along with all the other pmds? >>> >> Hi Panu, >> >> Good question :) >> >> I did wonder the same thing not long ago. >> >> I think the reason is that (someone may correct me if I'm wrong) there >> are specific unit tests for those pmds (testing extra API) that require >> them to always be linked against. > > A library is considered as a plugin if there is no public API and it > registers itself. That's the case of normal PMD. > But bonding and Xen have some library parts with public API. > It has been discussed and agreed for bonding but I'm not aware of the Xen case. Fair enough, thanks for the explanation. Just wondering about versioning of these things - currently all the PMDs are versioned as well, which is slightly at odds with their expected usage, dlopen()'ed items usually are not versioned because it makes the files moving targets. But if a plugin can be an library too then it clearly needs to be versioned as well. I'm just thinking of typical packaging where the unversioned *.so symlinks are in a -devel subpackage and the versioned libraries are in the main runtime package. Plugins should be loadable by a stable unversioned name always, for libraries the linker handles it behind the scenes. So in packaging these things, plugin *.so links need to be handled differently (placed into the main package) from others. Not rocket science to filter by 'pmd' in the name, but a new twist anyway and easy to get wrong. One possibility to make it all more obvious might be having a separate directory for plugins, the mixed case ccould be handled by symlinks. - Panu -