From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas.monjalon@6wind.com>
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com
 [209.85.212.177]) by dpdk.org (Postfix) with ESMTP id 470D9B48E
 for <dev@dpdk.org>; Fri, 13 Feb 2015 14:19:20 +0100 (CET)
Received: by mail-wi0-f177.google.com with SMTP id bs8so12034553wib.4
 for <dev@dpdk.org>; Fri, 13 Feb 2015 05:19:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:organization
 :user-agent:in-reply-to:references:mime-version
 :content-transfer-encoding:content-type;
 bh=xvrXfVZFYCLDAMYOkmpDRawXNSvRrRoO+ZBbiTR1XHE=;
 b=CjDMDgip42mBFJHFnl1S7QeQ/WsxzqObKmyHJPBPsKTNTCiw4Itxg8CbmYuymGnfu9
 94G6dCG86zVnI5SGLu2Iv9Gdxdihif2qajNmKXDBvwHwhbuo13iyw63PfYFhMG0c3MTq
 TqF+K8aDNMXUz5rmOdKX9eMmbmBXTDUAIDVtrq+ErPEtU4dFcfr71tIW3wAcW3iWUmd6
 EhG9T1RXfxUNstGdDLxjzjRtMVCEt/9cjQ0L6nBXWTvKbSjYN7eoCWweED/KSH0mv4bF
 ZF5IhSd81NMsPQDlsefUwFb3kLUwkhlg/D1bHPjIcRZtyWACrPstELY8s3RAz9iQ9RiS
 sRog==
X-Gm-Message-State: ALoCoQl7NSpDxX3DmdwCWseSRgRLhy7OCBwaQO97c5bccuFT4mCAi37iRgXDlYp9mFTtqN/GN2c3
X-Received: by 10.180.108.239 with SMTP id hn15mr7023412wib.38.1423833559077; 
 Fri, 13 Feb 2015 05:19:19 -0800 (PST)
Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136])
 by mx.google.com with ESMTPSA id fo9sm2922195wib.16.2015.02.13.05.19.17
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Fri, 13 Feb 2015 05:19:18 -0800 (PST)
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Panu Matilainen <pmatilai@redhat.com>
Date: Fri, 13 Feb 2015 14:18:48 +0100
Message-ID: <4225678.HUzObN4r7D@xps13>
Organization: 6WIND
User-Agent: KMail/4.14.4 (Linux/3.18.4-1-ARCH; KDE/4.14.4; x86_64; ; )
In-Reply-To: <54DDD2EE.7070505@redhat.com>
References: <6ca22ee1257e34ee2b89f2fb354d6c382b8f3e29.1423644785.git.pmatilai@redhat.com>
 <12066921.2HzVPH8BW6@xps13> <54DDD2EE.7070505@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Feb 2015 13:19:20 -0000

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?