Thanks for pointing that out, Chris. I have not tested changing shm permissions, but I see that I can "sudo vpp_api_test" directly and run commands without having to make any changes to /etc/sudoers like the one I needed to use vppctl in my setup.
Burt On Fri, Jun 2, 2017 at 6:27 PM, Luke, Chris <chris_l...@comcast.com> wrote: > 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> 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/ > 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> 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-bounces@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/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.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
