[dpdk-dev] kni: fix building on Ubuntu-hybrids
Commit Message
In the case where a userspace reports itself as Ubuntu, but the
kernel isn't providing the expected version signature interface,
turn off Ubuntu specializations.
This situation happens often enough in development environments,
and with multi-distribution build servers (e.g. chroot, containers).
Signed-off-by: Alexander Guy <alexander@andern.org>
---
lib/librte_eal/linuxapp/kni/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
2014-10-23 16:39, Alexander Guy:
> In the case where a userspace reports itself as Ubuntu, but the
> kernel isn't providing the expected version signature interface,
> turn off Ubuntu specializations.
>
> This situation happens often enough in development environments,
> and with multi-distribution build servers (e.g. chroot, containers).
[...]
> -ifeq ($(shell lsb_release -si 2>/dev/null),Ubuntu)
> +ifeq ($(shell test -f /proc/version_signature && lsb_release -si 2>/dev/null),Ubuntu)
Please, could explain what is the file /proc/version_signature and why
it can be a check for Ubuntu kernel?
Thanks
On Oct 24, 2014, at 12:35 AM, Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
>
> Please, could explain what is the file /proc/version_signature and why
> it can be a check for Ubuntu kernel?
Ubuntu provides /proc/version_signature to help with determining kernel lineage; it doesn’t exist in upstream kernels:
https://wiki.ubuntu.com/Kernel/FAQ#Kernel.2BAC8-FAQ.2BAC8-GeneralVersionRunning.How_can_we_determine_the_version_of_the_running_kernel.3F
Commit a09b359d started gathering version information via version_signature in order to enable certain Ubuntu-specific kernel workarounds. If you have a kernel without this information (e.g. upstream Linux v3.13 with an Ubuntu userspace), kni fails to build:
CC [M] /home/alexander/dpdk/build/build/lib/librte_eal/linuxapp/kni/e1000_82575.o
In file included from /home/alexander/dpdk/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_osdep.h:41:0,
from /home/alexander/dpdk/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_hw.h:31,
from /home/alexander/dpdk/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_api.h:31,
from /home/alexander/dpdk/build/build/lib/librte_eal/linuxapp/kni/e1000_82575.c:38:
/home/alexander/dpdk/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h:3864:8: error: macro "UBUNTU_KERNEL_VERSION" requires 5 arguments, but only 1 given
/home/alexander/dpdk/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h:3864:8: error: "UBUNTU_KERNEL_VERSION" is not defined [-Werror=undef]
My logic for the change is: if the build system is running in an environment that looks like Ubuntu, but can’t gather enough information to know if it should enable the kernel workarounds, it’s safe to not try to enable them at all.
Thanks.
Alexander
> In the case where a userspace reports itself as Ubuntu, but the
> kernel isn't providing the expected version signature interface,
> turn off Ubuntu specializations.
>
> This situation happens often enough in development environments,
> and with multi-distribution build servers (e.g. chroot, containers).
>
> Signed-off-by: Alexander Guy <alexander@andern.org>
Acked and applied.
Thanks
@@ -44,7 +44,7 @@ MODULE_CFLAGS += -I$(RTE_OUTPUT)/include -I$(SRCDIR)/ethtool/ixgbe -I$(SRCDIR)/e
MODULE_CFLAGS += -include $(RTE_OUTPUT)/include/rte_config.h
MODULE_CFLAGS += -Wall -Werror
-ifeq ($(shell lsb_release -si 2>/dev/null),Ubuntu)
+ifeq ($(shell test -f /proc/version_signature && lsb_release -si 2>/dev/null),Ubuntu)
MODULE_CFLAGS += -DUBUNTU_RELEASE_CODE=$(shell lsb_release -sr | tr -d .)
UBUNTU_KERNEL_CODE := $(shell cut -d' ' -f2 /proc/version_signature | \
cut -d'~' -f1 | cut -d- -f1,2 | tr .- $(comma))