From patchwork Mon Apr 30 07:17:31 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sirio Balmelli X-Patchwork-Id: 906505 X-Patchwork-Delegate: bpf@iogearbox.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=b-ad.ch Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=b-ad.ch header.i=@b-ad.ch header.b="CmgR0c3O"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 40ZG8n3pDPz9rvt for ; Mon, 30 Apr 2018 17:18:01 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752300AbeD3HRs (ORCPT ); Mon, 30 Apr 2018 03:17:48 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:45919 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751807AbeD3HRd (ORCPT ); Mon, 30 Apr 2018 03:17:33 -0400 Received: by mail-wr0-f193.google.com with SMTP id p5-v6so7017831wre.12 for ; Mon, 30 Apr 2018 00:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=b-ad.ch; s=google; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=4RKzgHS9BB5PekfL0K8U1v8goESWi512A4vm6v2vGp8=; b=CmgR0c3OGosFoC1n3cSf+tRt+YKlX11rm+krJBJbNyU/V6ktrTRpyFkgoNGNXNVR6E 2hdWN+Ru+MXv3qL7K93TtKnn9xamtCeedYzWtD4fq9Gdkx96ktGge9rPTNvFf3ptuZJv Gr6E5t6xQCEt9nMUepHOgOdHe8aRxHT+gja/NhG28lp9pa7YuVVtCSuQBRVknq16vtO2 lzjG9P+YffVbzkNTdFeHDVekk+7gsChAjIivaEHtMR0bdzNkhDbpzWQlNEbzJK8xxg9C QdgmjdQ0a98pqvZm/Z3hGZySdZbBZtBUCKMffMiBqH0Tzc/O5Yv/Li7HYPvTZoKRSNqG OC0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=4RKzgHS9BB5PekfL0K8U1v8goESWi512A4vm6v2vGp8=; b=s39sP3a3qTLWEtHZRLsBGhf2JttVrE6jM4JVRfS1e5dPPSu++pI8a8uEnn5asja7Wy QHqGgv9pbJdyFF3bzkWPdKqs4k8IK4bz4nK//eQ7DS2eMnjhRqy8dSFy+FcUtO2WHHL1 GkTD/Z8niXUOLczqAbNSqiLu5J3Rowm2zmAixifimqdWNuqlkjpMueNEuX6wuNhtKkYr XUH4egV/H0hzUapFS2gZL25moDe0MlB4kAKpgx8jcuIsceD2Gz/eFKaqf08DEcMIsJcK BH07XUCijRJtlmIV2tAKAbtGJS+zIGawRvczlQoXQUxowdFGXpd9vY9pzI/xgflYABSV 9yqw== X-Gm-Message-State: ALQs6tCUt3ZSIx/2xgU3VQsfwis2ZvjNVuAwX/hyma1lISwSvxcU/Frr ky1QICRtRW5Ho9w+Ag49xpZjcw83 X-Google-Smtp-Source: AB8JxZpXsXed3a8z0+bHghN4uGF/NKbE1FrmQTFz2SzilOCVmPBU2uBgmT8TZKUfV5KOfWUMfq3Ykg== X-Received: by 2002:adf:bd01:: with SMTP id j1-v6mr8419473wrh.69.1525072652823; Mon, 30 Apr 2018 00:17:32 -0700 (PDT) Received: from vm4 ([5.80.204.222]) by smtp.gmail.com with ESMTPSA id q17sm5712662wmf.3.2018.04.30.00.17.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Apr 2018 00:17:32 -0700 (PDT) Date: Mon, 30 Apr 2018 09:17:31 +0200 From: Sirio Balmelli To: daniel@iogearbox.net Cc: netdev@vger.kernel.org Subject: [PATCH v2 1/2] selftests/bpf: Makefile: add includes to fix broken test build Message-ID: <20180430071730.nghfksp2tkj3x5ld@vm4> MIME-Version: 1.0 Content-Disposition: inline User-Agent: NeoMutt/20180223 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Build fails with missing 'asm/bitsperlong.h'. Include this from tools/arch/[arch]/include/uapi using an architecture-specific include sourced from 'Module.symvers' (is this legitimate? another idea was to do a `uname -p` but what if caller was cross-compiling?) Once the arch-specific include is fixed, a lack of 'asm/byteorder.h' now rears its ugly head. The only sane (ie: will not pull in kernel headers) place I can find it is in $(ROOT)/usr/include - add this to the include. Note that $(ROOT)/usr/include is generated on kernel build, hence my assumption that 'Module.symvers' will also be present. This highlights a philosophical issue - should these tests build: 1. Against the kernel tree only? In this case I likely did the right thing here. 2. Against the local machine? Then the proper handling is to source 'arch' from eg `uname -p` and include /usr/include/x86_64-linux-gnu/asm/byteorder.h instead of $(ROOT)/usr/include. Signed-off-by: Sirio Balmelli --- tools/testing/selftests/bpf/Makefile | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile index 9d76218..a19c6af 100644 --- a/tools/testing/selftests/bpf/Makefile +++ b/tools/testing/selftests/bpf/Makefile @@ -84,8 +84,14 @@ else CPU ?= generic endif -CLANG_FLAGS = -I. -I./include/uapi -I../../../include/uapi \ - -Wno-compare-distinct-pointer-types +# Assume caller has compiled the kernel; get compilation architecture from Module.symvers +TOOLS :=../../.. +ROOT :=../../../.. +ARCH := $(shell sed -rne 's|.*(arch/[^/]+).*|\1|p' $(ROOT)/Module.symvers | head -n 1) +CLANG_FLAGS = -I. -I./include/uapi \ + -I$(TOOLS)/include/uapi -I$(TOOLS)/$(ARCH)/include/uapi \ + -I$(ROOT)/usr/include \ + -Wno-compare-distinct-pointer-types $(OUTPUT)/test_l4lb_noinline.o: CLANG_FLAGS += -fno-inline $(OUTPUT)/test_xdp_noinline.o: CLANG_FLAGS += -fno-inline