From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8FF1FC4332F for ; Thu, 10 Nov 2022 14:45:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231177AbiKJOpk (ORCPT ); Thu, 10 Nov 2022 09:45:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37580 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230494AbiKJOpj (ORCPT ); Thu, 10 Nov 2022 09:45:39 -0500 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 561A543AF6 for ; Thu, 10 Nov 2022 06:45:36 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id h133-20020a1c218b000000b003cf4d389c41so3569931wmh.3 for ; Thu, 10 Nov 2022 06:45:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=ElDuHUZHiM1bGpzs5ou38zzllblj5DI9IW1M1Yt0P50=; b=OaF5C7rzAKEgktC4eN0TcGzuvj550ImBQVe5qE+aFDCuuJaU6OPiTfHB1f9sEQJW1P a7KRiRplvHcfiGjzC8dHqePkZVHfK6NT59RLIxYCBeRs35MxrWFuZwhEAY3p5gFKMJ0Z Xm/JeWoAh7Qjzcq3GfOfWENu7QrvAQIEep/B31Cf4LdpP775ItTcySZ6IB1pyxBBd/iz HSpL3xaHK8zTDlfRZV9GVvUwxZLDpwcCf2rBhDInNIIA+sIq9E4g6bJDcbHq+TuexHgQ b7WkQ5yoXhYcFwxUAQD4tG9nZ2OFJqkDWtrcOCZSklyjKtlfFZwsk6GO7KbKEujLgpFp icXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ElDuHUZHiM1bGpzs5ou38zzllblj5DI9IW1M1Yt0P50=; b=pyrJFF8J4NlO2WBX4QLYMjWf+1GFOiiWXE8seQOpiEde2CLnGO+f3H+fHvJ4PuCFDj UgqaK313UpFPLYZRUd/rQcyxNjje82Cm37Dw/TnKU1FEMy89wgkFeRjTEU02SaNE+deL ZN2qsrBrmOUxOEBiPoE5e/CuPfFU+ymvbnusT5FM9tP/SQ0To6P5kQFU+MYtIX+1lvy0 V4VltfOjhMX36yjbFy3A1cz4YmQKlu6kqJFFjIz3uNYJ3dDly7tXKJgVL1RxbLYzxCom s97s4VhYiRfHnx2DNQxZogpiBnB7Uz/sclDZ/rLVg/FteA89uiDqio3zc+A+jTqdB0zN 15LA== X-Gm-Message-State: ACrzQf3wZyH1QiT6Ecj3K/KpeR29jeuYeLceouInyYwx6B1J5BQcVmo+ BFEzyTj6c5bCaMcPiqFoUV61BFpizocuRLRNwd8= X-Google-Smtp-Source: AMsMyM6ZyCI5gRrCxV6Griy0N+86N9+UUa1vir1qlm25yDQNFlgP8KiD1FGW9nWQ1klM1KK+SvkcnA== X-Received: by 2002:a05:600c:2053:b0:3cf:9b39:8585 with SMTP id p19-20020a05600c205300b003cf9b398585mr21533827wmg.106.1668091534904; Thu, 10 Nov 2022 06:45:34 -0800 (PST) Received: from localhost ([95.148.15.66]) by smtp.gmail.com with ESMTPSA id n15-20020a05600c3b8f00b003c6c3fb3cf6sm6368356wms.18.2022.11.10.06.45.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Nov 2022 06:45:34 -0800 (PST) From: Punit Agrawal To: Shuah Khan Cc: Punit Agrawal , akpm@linux-foundation.org, shuah@kernel.org, adobriyan@gmail.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [External] Re: [PATCH v2 1/2] selftests: proc: Fix proc-empty-vm build error on non x86_64 References: <20221109221104.1797802-1-punit.agrawal@bytedance.com> <6b6cd1e2-3ab7-eede-e04b-738bbcbb5760@linuxfoundation.org> Date: Thu, 10 Nov 2022 14:45:33 +0000 In-Reply-To: <6b6cd1e2-3ab7-eede-e04b-738bbcbb5760@linuxfoundation.org> (Shuah Khan's message of "Wed, 9 Nov 2022 17:20:23 -0700") Message-ID: <87tu36zx4i.fsf@stealth> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org Hi Shuah, Shuah Khan writes: > On 11/9/22 15:11, Punit Agrawal wrote: >> The proc-empty-vm test is implemented for x86_64 and fails to build >> for other architectures. Rather then emitting a compiler error it >> would be preferable to only build the test on supported architectures. >> Mark proc-empty-vm as a test for x86_64 and customise the Makefile >> to >> build it only when building for this target architecture. >> Fixes: 5bc73bb3451b ("proc: test how it holds up with mapping'less >> process") >> Signed-off-by: Punit Agrawal >> --- >> v1 -> v2 >> * Fixed missing compilation on x86_64 >> Previous version >> * https://lore.kernel.org/all/20221109110621.1791999-1-punit.agrawal@bytedance.com/ >> tools/testing/selftests/proc/Makefile | 10 ++++++++-- >> 1 file changed, 8 insertions(+), 2 deletions(-) >> diff --git a/tools/testing/selftests/proc/Makefile >> b/tools/testing/selftests/proc/Makefile >> index cd95369254c0..743aaa0cdd52 100644 >> --- a/tools/testing/selftests/proc/Makefile >> +++ b/tools/testing/selftests/proc/Makefile >> @@ -1,14 +1,16 @@ >> # SPDX-License-Identifier: GPL-2.0-only >> + >> +# When ARCH not overridden for crosscompiling, lookup machine >> +ARCH ?= $(shell uname -m 2>/dev/null || echo not) >> + >> CFLAGS += -Wall -O2 -Wno-unused-function >> CFLAGS += -D_GNU_SOURCE >> LDFLAGS += -pthread >> -TEST_GEN_PROGS := >> TEST_GEN_PROGS += fd-001-lookup >> TEST_GEN_PROGS += fd-002-posix-eq >> TEST_GEN_PROGS += fd-003-kthread >> TEST_GEN_PROGS += proc-loadavg-001 >> -TEST_GEN_PROGS += proc-empty-vm >> TEST_GEN_PROGS += proc-pid-vm >> TEST_GEN_PROGS += proc-self-map-files-001 >> TEST_GEN_PROGS += proc-self-map-files-002 >> @@ -26,4 +28,8 @@ TEST_GEN_PROGS += thread-self >> TEST_GEN_PROGS += proc-multiple-procfs >> TEST_GEN_PROGS += proc-fsconfig-hidepid >> +TEST_GEN_PROGS_x86_64 += proc-empty-vm > > Why do you need this? You already have conditional compiles. > Conditionally add proc-empty-vm to TEST_GEN_PROGS like other > tests do. I copied this approach from KVM tests. Looks like we've got a few different ways of disabling compilation within selftests. I can respin to conditionally compile as suggested if that is the way forward. >> + >> +TEST_GEN_PROGS += $(TEST_GEN_PROGS_$(ARCH)) >> + >> include ../lib.mk > > Same question Andrews asked you. What does it take to get this > to work on other architectures. proc and vm tests should be > arch. agnostic as a rule unless it is absolutely necessary to > have them acrh. aware. Please see my reply elsewhere in the thread for an assessment of the architecture dependencies.