It should be possible to set the shm permissions such that vpp_api_test can be run as a non-privileged user; that being the case, don’t use the vppctl wrapper script, just invoke vat directly.
Note I’ve not tested this in a while; but we did make it possible last year iirc. Chris. From: Burt Silverman [mailto:bur...@gmail.com] Sent: Friday, June 2, 2017 17:54 To: Damjan Marion (damarion) <damar...@cisco.com>; Dave Barach <d...@barachs.net> Cc: Kinsella, Ray <ray.kinse...@intel.com>; Luke, Chris <chris_l...@cable.comcast.com>; Alessio Silvestro <ale.silver...@gmail.com>; vpp-dev <vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] VPP/How To Build The Sample Plugin 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<mailto: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<mailto: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/install-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<mailto:damar...@cisco.com>> wrote: > > On 31 May 2017, at 18:18, Kinsella, Ray > <ray.kinse...@intel.com<mailto: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<http://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<mailto: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<mailto: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> >>>>>> [mailto: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<mailto:ray.kinse...@intel.com>> >>>>>> *Cc:* Alessio Silvestro >>>>>> <ale.silver...@gmail.com<mailto:ale.silver...@gmail.com>>; vpp-dev >>>>>> <vpp-dev@lists.fd.io<mailto: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> >>>>>> <mailto: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/lib64/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.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> >>>>>> <mailto: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> >>>>>> <mailto: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 >>>> >>
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
