From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by dpdk.org (Postfix) with ESMTP id 2A02AB5AC for ; Mon, 16 Feb 2015 12:18:21 +0100 (CET) Received: by mail-we0-f172.google.com with SMTP id k48so28547375wev.3 for ; Mon, 16 Feb 2015 03:18:21 -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=vQ9iiJTRUNIsjvckD2fdqop4riz/m2AIbxTcLvl7H+0=; b=AtWlmkcM8X9SK/eUQ5qcIgPNjpF9YCM1h9znXsWoLvHu1iWwSG2U6Ql9ChExuRyJxP W9jKEeR6MkO3Yp7edHfd3IOfoOVavahucXRtIJZ8o8x31na6XUiUib8Rw9Nm+OUzZyKH XyvsAOOBrMT8CDpSiMwbSWQIqBfo1S18cVKWTdmRG2gBUnnYm8fwMoodJ8/3cw1veCY/ RKy+7Yz5+hAiJBrNskYZm7GYiEV0k4YMHDPAZI7ciZ/JpvqC0c7/i/xheXfBdZkNoKUO Eont47wkW7ZzKe6oN/3NC+dp9Mj4T6yYJclGk0NRVpeM9MhTInW9cFXh9ql/9uipbghQ JUoA== X-Gm-Message-State: ALoCoQlivgqH9tnxVWRdb3UQvfvhWVLYpABFP7bGag/j+BZBLprfz+siByVK+AJ5AxOZ53dpNeyx X-Received: by 10.180.95.162 with SMTP id dl2mr45442940wib.31.1424085500955; Mon, 16 Feb 2015 03:18:20 -0800 (PST) Received: from xps13.localnet (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id eb10sm19219295wib.13.2015.02.16.03.18.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Feb 2015 03:18:20 -0800 (PST) From: Thomas Monjalon To: Panu Matilainen Date: Mon, 16 Feb 2015 12:17:45 +0100 Message-ID: <4097369.UqpyrEhzLH@xps13> Organization: 6WIND User-Agent: KMail/4.14.4 (Linux/3.18.4-1-ARCH; KDE/4.14.4; x86_64; ; ) In-Reply-To: <54E1BFFD.2010507@redhat.com> References: <6ca22ee1257e34ee2b89f2fb354d6c382b8f3e29.1423644785.git.pmatilai@redhat.com> <4225678.HUzObN4r7D@xps13> <54E1BFFD.2010507@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 11:18:21 -0000 2015-02-16 12:01, Panu Matilainen: > 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)? I'm thinking of "-D ". I understand you would like a "hardwired" default directory which would be properly packaged by a distribution. Maybe that it could be a build-time default to load all the plugins of a directory (without option). Then the -d and -D options would overwrite the build-time default behaviour.