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 0A272B5B6 for ; Mon, 16 Feb 2015 11:01:38 +0100 (CET) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1GA1ZWQ026800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 16 Feb 2015 05:01:35 -0500 Received: from localhost.localdomain (vpn1-5-228.ams2.redhat.com [10.36.5.228]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1GA1XFG010635; Mon, 16 Feb 2015 05:01:34 -0500 Message-ID: <54E1BFFD.2010507@redhat.com> Date: Mon, 16 Feb 2015 12:01:33 +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 References: <6ca22ee1257e34ee2b89f2fb354d6c382b8f3e29.1423644785.git.pmatilai@redhat.com> <12066921.2HzVPH8BW6@xps13> <54DDD2EE.7070505@redhat.com> <4225678.HUzObN4r7D@xps13> In-Reply-To: <4225678.HUzObN4r7D@xps13> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 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: Mon, 16 Feb 2015 10:01:39 -0000 On 02/13/2015 03:18 PM, Thomas Monjalon wrote: > 2015-02-13 12:33, Panu Matilainen: >> On 02/13/2015 11:28 AM, Thomas Monjalon wrote: >>> 2015-02-13 09:27, Panu Matilainen: >>>> On 02/12/2015 05:44 PM, Thomas Monjalon wrote: >>>>> 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. >>> >>> Not sure to understand your considerations. >>> Plugins must be versioned because there can be some incompatibilities >>> like mbuf rework. >> >> Plugins are version-dependent obviously, but the issue is somewhat >> different from library versioning. Plugins are generally consumers of >> the versioned ABIs, whereas libraries are the providers. >> >>>> 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. >>> >>> I think I don't understand which use case you are trying to solve. >> >> Its a usability/documentation issue more than a technical one. If plugin >> DSO's are versioned (like they currently are), then loading them via eg >> -d becomes cumbersome since you need to hunt down and provide the >> versioned name, eg "testpmd -d librte_pmd_pcap.so.1 [...]" >> >> Like said above, it can be worked around by leaving the unversioned >> symlinks in place for plugins in runtime (library) packages, but that >> sort of voids the point of versioning. One possibility would be >> introducing a per-version plugin directory that would be used as the >> default path for dlopen() unless an absolute path is used. > > It makes me think that instead of using a -d option per plugin, why not > adding a -D option to load all plugins from a directory? Are you thinking of "-D " or just -D (to use a build-time hardwired directory)? - Panu -