From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by dpdk.org (Postfix) with ESMTP id E9FBFB3D8 for ; Fri, 13 Feb 2015 10:28:54 +0100 (CET) Received: by mail-wi0-f175.google.com with SMTP id r20so10521272wiv.2 for ; Fri, 13 Feb 2015 01:28:54 -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=P2dhZwldVtUAiERZIbuLJI2cnmJO0TPXXntXjDHmO2E=; b=lGW47vVIZ2dOoi+rSCR1nareZENPB3otqBCNltW+PI2vTvqQfZjbIRIu/rVg6Sn+UZ mwqJ+GcvAzpXb/lg3wpntyeDZps7R9VPzXT2JW3X7myaIKH5CIp8Vdh9dvXhw5TWcfdj /jrSPOwKQmJk4XkLp+dnUbVX8Dl00Oopo+oJyQK/BINkuLHIGyxFdKQomQ63foPbR97V dIEXJYZ+XQGSObU2JtmwQy5bv2n8UpuBqHw0ugOPWCntrl6UVah25VOS9lhVUjijWqIh s79yYloA6dJ2R7h8FF9AA3LWxr1HawLm5CksyYljdvghzT7y7vrYKAqrXtQ5Fl4BbHk6 4W1A== X-Gm-Message-State: ALoCoQm+ls/zPtmQGh/NGFIq6CgBqDyPhpdID+4NwFtgwmR3YdNSc5ZcWIdseROM40xg0D1PDAxX X-Received: by 10.194.95.66 with SMTP id di2mr4034606wjb.57.1423819734695; Fri, 13 Feb 2015 01:28:54 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id l6sm9267103wjx.33.2015.02.13.01.28.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Feb 2015 01:28:53 -0800 (PST) From: Thomas Monjalon To: Panu Matilainen Date: Fri, 13 Feb 2015 10:28:24 +0100 Message-ID: <12066921.2HzVPH8BW6@xps13> Organization: 6WIND User-Agent: KMail/4.14.4 (Linux/3.18.4-1-ARCH; KDE/4.14.4; x86_64; ; ) In-Reply-To: <54DDA759.3060908@redhat.com> References: <6ca22ee1257e34ee2b89f2fb354d6c382b8f3e29.1423644785.git.pmatilai@redhat.com> <3129786.dHlkKq5arh@xps13> <54DDA759.3060908@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: Fri, 13 Feb 2015 09:28:55 -0000 2015-02-13 09:27, Panu Matilainen: > 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. Not sure to understand your considerations. Plugins must be versioned because there can be some incompatibilities like mbuf rework. > 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.