On Thu, Jul 23, 2015 at 12:15:29PM -0400, Mussar, Gary wrote: > > > > -----Original Message----- > > From: Ben Pfaff [mailto:b...@nicira.com] > > Sent: Thursday, July 23, 2015 11:47 > > To: Mussar, Gary > > Cc: dev@openvswitch.org > > Subject: Re: [ovs-dev] FW: [PATCH V2 1/1] Fix detection of vhost_cuse in > > dpdk rte_config.h > > > > On Thu, Jul 23, 2015 at 11:09:32AM -0400, Mussar, Gary wrote: > > > Dpdk allows users to create a config that includes other config files > > > and then override values. > > > > > > Eg. > > > defconfig_x86_64-native_vhost_cuse-linuxapp-gcc: > > > > > > CONFIG_RTE_BUILD_COMBINE_LIBS=y > > > CONFIG_RTE_BUILD_SHARED_LIB=n > > > CONFIG_RTE_LIBRTE_VHOST=y > > > CONFIG_RTE_LIBRTE_VHOST_USER=n > > > > > > This allows you to have both a vhostuser and vhostcuse config in the > > > same source tree without the need to replicate everything in those > > > config files just to change a couple of settings. The resultant > > > .config file has all of the settings from the included files with the > > updated settings at the end. > > > The resultant rte_config.h contains multiple undefs and defines for > > > the overridden settings. > > > > > > Eg. > > > > grep RTE_LIBRTE_VHOST_USER x86_64-native_vhost_cuse-linuxapp- > > gcc/include/rte_config.h > > > #undef RTE_LIBRTE_VHOST_USER > > > #define RTE_LIBRTE_VHOST_USER 1 > > > #undef RTE_LIBRTE_VHOST_USER > > > > > > The current mechanism to detect the RTE_LIBRTE_VHOST_USER setting > > > merely greps the rte_config.h file for the string "define > > RTE_LIBRTE_VHOST_USER 1" > > > rather than the final setting of RTE_LIBRTE_VHOST_USER. The following > > > patch changes this test to detect the final setting of > > RTE_LIBRTE_VHOST_USER. > > > > > > Signed-off-by: Gary Mussar <gmus...@ciena.com> > > > --- > > > acinclude.m4 | 5 ++++- > > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > > > diff --git a/acinclude.m4 b/acinclude.m4 index 3604e55..0e05468 100644 > > > --- a/acinclude.m4 > > > +++ b/acinclude.m4 > > > @@ -175,7 +175,10 @@ AC_DEFUN([OVS_CHECK_DPDK], [ > > > DPDK_LIB="-lintel_dpdk" > > > DPDK_EXTRA_LIB="" > > > > > > - OVS_GREP_IFELSE([$RTE_SDK/include/rte_config.h], [define > > RTE_LIBRTE_VHOST_USER 1], > > > + AC_EGREP_CPP([int vhost = 1;], [ > > > +#include <$RTE_SDK/include/rte_config.h> int vhost = > > > +RTE_LIBRTE_VHOST_USER; ], > > > [], [AC_DEFINE([VHOST_CUSE], [1], [DPDK vhost-cuse > > support enabled, vhost-user disabled.]) > > > DPDK_EXTRA_LIB="-lfuse"]) > > > > We use OVS_GREP_IFELSE for kernel checks because it's relatively > > difficult to get the kernel build system to compile a random fragment of > > text for us, but it's somewhat odd to use AC_EGREP_CPP to detect the value > > of something when we can easily do a real compile. The usual Autoconf > > test for something like this would be more like: > > > > AC_COMPILE_IFELSE( > > [AC_LANG_PROGRAM( > > [[#include <rte_config.h> > > #if !RTE_LIBRTE_VHOST_USER > > choke me > > #endif]])], > > [...if it's present...], > > [...if it's missing....]) > > > > and then you don't worry about someone changing the definition of the > > macro to "(1)" or "true". > > > > I have seen it done both ways although preprocessing isn't done as often as > compiling. It seemed to me that preprocessing was a smaller step from just > original OVS_GREP_IFELSE of the header file itself. I assume you want the > patch changed to compile, right?
That's my own preference, but I consider Pravin authoritative here. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
