OK, I figured out how to patch code to add a vat_plugin_path option to
/etc/vpp/startup.conf, but that was not the answer to the immediate issue,
regarding my failure to get output from "show pci" under vppctl, when
running from /home/burt/vpp/build-root/install-vpp-native/vpp/bin.
The issue is that vppctl wants to run a command in this directory as sudo.
The command is not found because of sudo. There are two fixes in addition
to building and installing packages:
1. Copy the program vpp_api_test from the aforementioned directory to
/usr/bin.
The problem with this approach is that you have to know each time you
build whether you have changed vpp_api_test and hence need to recopy it to
/usr/bin.
2. Use sudoedit to add your bin directory (like
/home/burt/vpp/build-root/install-vpp-native/vpp/bin) to the secure_path in
the /etc/sudoers file.
Then you are good for as long as you do not change the location of
your tree.
Forgive me for hijacking this sample vpp-plugin thread for a slightly
different discussion.
Perhaps someone can let me know if this appears usable, or close to usable,
or far!
[burt@localhost ~/vpp/src/vpp]$git diff .
diff --git a/src/vpp/vnet/main.c b/src/vpp/vnet/main.c
index ade32aa..1bc190f 100644
--- a/src/vpp/vnet/main.c
+++ b/src/vpp/vnet/main.c
@@ -20,6 +20,7 @@
#include <vnet/ethernet/ethernet.h>
#include <vpp/app/version.h>
#include <vpp/api/vpe_msg_enum.h>
+#include "vat/vat.h"
static void
@@ -162,6 +163,11 @@ main (int argc, char *argv[])
if (i < (argc - 1))
vlib_plugin_path = argv[++i];
}
+ else if (!strncmp (argv[i], "vat_plugin_path", 15))
+ {
+ if (i < (argc - 1))
+ vat_plugin_path = argv[++i];
+ }
else if (!strncmp (argv[i], "heapsize", 8))
{
sizep = (u8 *) argv[i + 1];
@@ -252,6 +258,16 @@ plugin_path_config (vlib_main_t * vm, unformat_input_t
* in
VLIB_CONFIG_FUNCTION (plugin_path_config, "plugin_path");
+static clib_error_t *
+vat_plugin_path_config (vlib_main_t * vm, unformat_input_t * input)
+{
+ clib_error_t *error;
+
+ error = plugin_path_config (vm, input);
+ return error;
+}
+VLIB_CONFIG_FUNCTION (vat_plugin_path_config, "vat_plugin_path");
+
void vl_msg_api_post_mortem_dump (void);
void elog_post_mortem_dump (void);
Burt
On Thu, Jun 1, 2017 at 1:43 PM, Burt Silverman <bur...@gmail.com> wrote:
> Oh, man, that (referring to my last post) is some tricky stuff. My
> reaction reminds me of one of my colleagues reaction years ago when I
> created some firmware that would only fit in flash by using an AIX C
> compiler optimization trick that discarded uncalled functions. After I told
> him the solution he required, he exclaimed loudly, "OH, I THINK IT STINKS."
> Now, one of my issues, not the primary question, but the "stinks" issue, is
> that there are at least two unique load_one_plugin functions that behave
> differently but both show up in the log as "load_one_plugin."
>
> OK, the function in vlib/unix/plugin.c will not accept my
> vpp_api_test_plugins even though I have them in the plugin path I
> configured in /etc/vpp/startup.conf, because they do not have section
> vlib_plugin_registration in the ELF. I think there is a separate
> vat_plugin_path that is hard coded to /usr/lib/vpp_api_test_plugins in
> vpp/api/plugin.c. How can I configure this so that I can have these vat
> plugins in $TOP/build-root/install-vpp-native/vpp/lib64/vpp_api_test_plugins?
> As I have mentioned earlier, I am trying to come up with a developer work
> flow that does not require building and installing packages.
>
> Burt
>
> On Wed, May 31, 2017 at 3:56 PM, Burt Silverman <bur...@gmail.com> wrote:
>
>> Damjan,
>>
>> I have a related question, but it does not involve the sample-plugin. I
>> wish to "make build-release" and then adjust my plugin path in
>> /etc/vpp/startup.conf to use the plugin directories underneath
>> TOP/build-root/install-vpp-native/vpp/lib64. Well it seems that the
>> plugins in directory vpp_plugins are acceptable, but the ones in
>> vpp_api_test_plugins are not. I end up with a result like:
>>
>> [burt@localhost ~]$source ./vpp.sh
>> [sudo] password for burt:
>> vlib_plugin_early_init:356: plugin path /home/burt/vpp/build-root/inst
>> all-vpp-native/vpp/lib64/vpp_plugins:/home/burt/vpp/build-
>> root/install-vpp-native/vpp/lib64/vpp_api_test_plugins
>> load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
>> load_one_plugin:83: Not a plugin: acl_test_plugin.so
>> load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data Plane
>> Development Kit (DPDK))
>> load_one_plugin:83: Not a plugin: dpdk_test_plugin.so
>> load_one_plugin:184: Loaded plugin: flowperpkt_plugin.so (Flow per Packet)
>> load_one_plugin:83: Not a plugin: flowperpkt_test_plugin.so
>> ...
>> load_one_plugin:63: Loaded plugin: /usr/lib/vpp_api_test_plugins/
>> acl_test_plugin.so
>> load_one_plugin:63: Loaded plugin: /usr/lib/vpp_api_test_plugins/
>> dpdk_test_plugin.so
>> load_one_plugin:63: Loaded plugin: /usr/lib/vpp_api_test_plugins/
>> flowperpkt_test_plugin.so
>> load_one_plugin:63: Loaded plugin: /usr/lib/vpp_api_test_plugins/
>> gtpu_test_plugin.so
>> ...
>> [but I want it to work without installing the vpp-plugins package]
>>
>> Can it be fixed easily? It seems that I cannot use the vppctl program
>> ("show pci" for example) without the test plugins (or I am missing
>> something else.)
>>
>> Thanks.
>>
>> Burt
>>
>> On Wed, May 31, 2017 at 12:31 PM, Damjan Marion (damarion) <
>> damar...@cisco.com> wrote:
>>
>>> >
>>> > On 31 May 2017, at 18:18, Kinsella, Ray <ray.kinse...@intel.com>
>>> wrote:
>>> >
>>> >
>>> > Ok - but that doesn't get us any closer to helping newbies use the
>>> sample plugin with 'make build' and 'make run', right? They still need to
>>> install vpp, then the sample-plugin - lots of hoops.
>>>
>>> make run is not built for running out-of-tree plugins but this should
>>> work:
>>>
>>> make bootstrap
>>> make pkg-deb
>>> dpkg -i build-root/*.deb
>>> cd src/examples/sample-plugin
>>> autoreconf -fis
>>> ./configure
>>> make
>>> sudo make install
>>>
>>> >
>>> > I disagree with a documentation heavy approach in principle, the wiki
>>> suggests, that it similarly goes 'out of sync' quiet quickly.
>>> >
>>> > BTW - I wasn't advocating PLUGIN_DISABLED, I provided build-data
>>> configs in the same way we do enabling/disabling dpdk features.
>>>
>>> ok
>>>
>>> >
>>> > The updated patch provides the separation between example/sample
>>> plugins and plugins that was asked for. It re-uses all the same autotools
>>> configs as src/plugins, so shouldn't go out of sync.
>>>
>>> i still disagree, sample-plugin should be stand-alone autotools project,
>>> you are removing configure.ac so for me it is no-go.
>>>
>>> >
>>> > Ray K
>>> >
>>> >
>>> > On 31/05/2017 17:05, Damjan Marion (damarion) wrote:
>>> >>
>>> >> I do not agree with that proposal, I think we need to have one sample
>>> of out-of-tree plugin as it is today.
>>> >>
>>> >> Still, I agree that we need to help newbies and my proposal is that
>>> we just document build process for out-of-tree plugins with simple
>>> README.md inside src/examples/sample-plugin.
>>> >>
>>> >> btw I consider use of PLUGIN_DISABLED (as default choice) as evil, as
>>> it mens that plugin will go out of sync sooner or later.
>>> >>
>>> >>
>>> >>> On 31 May 2017, at 17:37, Kinsella, Ray <ray.kinse...@intel.com>
>>> wrote:
>>> >>>
>>> >>>
>>> >>> Ok, typically example/sample code is intended to be used by the
>>> newest of the new, newbies. So the sample plugin should work with 'make
>>> build' and 'make run' with the minimum of hoops to enable. Asking these
>>> users to install and configure VPP, then do the same for the sample plugin
>>> is too much. I think that this thread exists, is testament that the UX
>>> could be better - too many hoops.
>>> >>>
>>> >>> So here I what I suggest to fix.
>>> >>>
>>> >>> We create src/examples/plugins, put the sample plugin in here.
>>> >>>
>>> >>> The examples plugins (src/examples/plugins) are in-tree plugins and
>>> build in exactly the same way as src/plugins from a build PoV
>>> (PLUGIN_ENABLED etc), with the exception that the examples plugins are
>>> disabled by default. They also live in the sample directory with no
>>> symlinks etc to src/plugin. We then provide a way to explicitly enable them
>>> with a build-data config.
>>> >>>
>>> >>> I reworked the patch along these lines, does it make sense?
>>> >>>
>>> >>> Ray K
>>> >>>
>>> >>> On 31/05/2017 10:15, Damjan Marion (damarion) wrote:
>>> >>>>
>>> >>>> The idea of sample plugin is to show people how to build
>>> out-of-tree plugin. As that plugin was broken several times due to changes
>>> we made I created special ebuild package which builds sample plugin as part
>>> of verify job to ensure that plugin will not be broken again due to changes
>>> in vpp.
>>> >>>>
>>> >>>> Saying that, I strongly disagree that we move sample plugin into
>>> src/plugins, as that is place for in-tree plugins which actually do
>>> something useful.
>>> >>>> If people want to create additional in-tree plugin, there is many
>>> samples already in src/plugins so I don't see an need for additional one.
>>> >>>>
>>> >>>> So to continue discussion on this particular change, what do you
>>> think that it is broken?
>>> >>>>
>>> >>>> For me sequence:
>>> >>>>
>>> >>>> autoreconf -fis
>>> >>>> ./configure
>>> >>>> make
>>> >>>> make install
>>> >>>>
>>> >>>> Works perfectly fine. Off-course you need to have install vpp-dev
>>> package on your system...
>>> >>>>
>>> >>>>
>>> >>>>> On 30 May 2017, at 13:30, Kinsella, Ray <ray.kinse...@intel.com>
>>> wrote:
>>> >>>>>
>>> >>>>> The UX for the sample plugin is broken. Especially when you
>>> consider that the people most likely to try it and use it, are those least
>>> familiar with VPP.
>>> >>>>>
>>> >>>>> I tried the use it a few months ago in training and found the UX
>>> similar then. So I put together a number of changes to integrate the plugin
>>> into the VPP build system, provide a build var to enable and disable it,
>>> and then added documentation for anyone new to VPP.
>>> >>>>>
>>> >>>>> https://gerrit.fd.io/r/#/c/6920/
>>> >>>>>
>>> >>>>> Thanks,
>>> >>>>>
>>> >>>>> Ray K
>>> >>>>>
>>> >>>>> On 27/05/2017 18:27, Luke, Chris wrote:
>>> >>>>>> Wishes often come true when you turn them into patches. :)
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> Chris.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> *From:* vpp-dev-boun...@lists.fd.io [mailto:
>>> vpp-dev-boun...@lists.fd.io]
>>> >>>>>> *On Behalf Of *Burt Silverman
>>> >>>>>> *Sent:* Saturday, May 27, 2017 10:33
>>> >>>>>> *To:* Kinsella, Ray <ray.kinse...@intel.com>
>>> >>>>>> *Cc:* Alessio Silvestro <ale.silver...@gmail.com>; vpp-dev
>>> >>>>>> <vpp-dev@lists.fd.io>
>>> >>>>>> *Subject:* Re: [vpp-dev] VPP/How To Build The Sample Plugin
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> Thanks, Ray, this is exactly what I needed, by coincidence. I
>>> wish your
>>> >>>>>> item 2. was placed commented out and almost word for word into the
>>> >>>>>> standard $TOPDIR/src/vpp/conf/startup.conf -- that would make
>>> things
>>> >>>>>> self documenting.
>>> >>>>>>
>>> >>>>>> Burt
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> On Sat, May 27, 2017 at 8:30 AM, Kinsella, Ray <
>>> ray.kinse...@intel.com
>>> >>>>>> <mailto:ray.kinse...@intel.com>> wrote:
>>> >>>>>>
>>> >>>>>> So there is an easier way
>>> >>>>>>
>>> >>>>>> 1. make -C build-root PLATFORM=vpp TAG=vpp sample-plugin-install
>>> >>>>>>
>>> >>>>>> 2. adjusting the plugin path depending on where the VPP src is,
>>> add
>>> >>>>>> the following to your startup.conf
>>> >>>>>>
>>> >>>>>> plugins
>>> >>>>>> {
>>> >>>>>> path
>>> >>>>>> /root/src/vpp/build-root/install-vpp-native/sample-plugin/li
>>> b64/vpp_plugins/:/root/src/vpp/build-root/install-vpp_debug-
>>> native/vpp/lib64/vpp_plugins
>>> >>>>>> }
>>> >>>>>>
>>> >>>>>> Ray K
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> On 26/05/2017 12:53, Alessio Silvestro wrote:
>>> >>>>>>
>>> >>>>>> Hi all,
>>> >>>>>>
>>> >>>>>> I am trying to build the sample vpp-engine plug-in as
>>> explained here
>>> >>>>>> (https://wiki.fd.io/view/VPP/How_To_Build_The_Sample_Plugin
>>> >>>>>> <https://wiki.fd.noclick_io/view/VPP/How_To_Build_The_Sample
>>> _Plugin>).
>>> >>>>>>
>>> >>>>>> I already tested my vpp installation, for instance it works
>>> when I
>>> >>>>>> created a Source NAT.
>>> >>>>>>
>>> >>>>>> I downloaded the most updated version of the sample-plugin and
>>> >>>>>> run the
>>> >>>>>> following commands:
>>> >>>>>>
>>> >>>>>> sudo sh
>>> >>>>>> cd /usr/share/doc/vpp/examples
>>> >>>>>> cd /tmp/sample-plugin
>>> >>>>>> libtoolize
>>> >>>>>> aclocal
>>> >>>>>> autoconf
>>> >>>>>> autoheader
>>> >>>>>>
>>> >>>>>> ERROR 1:autoheader: error: AC_CONFIG_HEADERS not found in
>>> >>>>>> configure.ac <http://configure.noclick_ac>
>>> >>>>>> <http://configure.ac <http://configure.noclick_ac>>
>>> >>>>>>
>>> >>>>>> automake --add-missing
>>> >>>>>> chmod +x configure
>>> >>>>>> vpp_plugin_configure
>>> >>>>>>
>>> >>>>>> ERROR 2:vpp_plugin_configure: command not found
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> So, first I have an error from the command autoheader.
>>> >>>>>>
>>> >>>>>> Second, I do not have the command vpp_plugin_configure.
>>> >>>>>>
>>> >>>>>> Any hints?
>>> >>>>>>
>>> >>>>>> Best regards,
>>> >>>>>> Alessio
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> _______________________________________________
>>> >>>>>> vpp-dev mailing list
>>> >>>>>> vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
>>> >>>>>> https://lists.fd.io/mailman/listinfo/vpp-dev
>>> >>>>>> <https://lists.fd.noclick_io/mailman/listinfo/vpp-dev>
>>> >>>>>>
>>> >>>>>> _______________________________________________
>>> >>>>>> vpp-dev mailing list
>>> >>>>>> vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
>>> >>>>>> https://lists.fd.io/mailman/listinfo/vpp-dev
>>> >>>>>> <https://lists.fd.noclick_io/mailman/listinfo/vpp-dev>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>> _______________________________________________
>>> >>>>> vpp-dev mailing list
>>> >>>>> vpp-dev@lists.fd.io
>>> >>>>> https://lists.fd.io/mailman/listinfo/vpp-dev
>>> >>>>
>>> >>
>>>
>>>
>>
>
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
