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 X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1FE43ECE599 for ; Wed, 16 Oct 2019 21:04:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E94CF20872 for ; Wed, 16 Oct 2019 21:04:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="FWkoFloQ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2437362AbfJPVEr (ORCPT ); Wed, 16 Oct 2019 17:04:47 -0400 Received: from mail-pf1-f193.google.com ([209.85.210.193]:41730 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2437357AbfJPVEr (ORCPT ); Wed, 16 Oct 2019 17:04:47 -0400 Received: by mail-pf1-f193.google.com with SMTP id q7so153330pfh.8 for ; Wed, 16 Oct 2019 14:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5DXDICv1BrxMLav/y/sfl9xCxyyzw1drlgwbHD31nnY=; b=FWkoFloQxqdaQka3gkSOdU2FjYC82UVpcLvBPA+LhkTGD2zoh1EqJ/NJcg/VuM9xMw LQPtwTu+DqbdtcrjLCaLgAIgngoW3vpTVInKU4Me3dquBIDQVLnrR1YVrcsQWXKT5X+O ikZFC1UaNa2r2IIfJ+3essGQck5FXh05KI35c0sB3QbhKUv6vvAgjQBSWzi3zeYMKf95 zm5enTgoOz1Zvs20nQiB1aR9xElr4/PVPH8CKY5o5xJxFcb+l0LUquBzHNbJguy0Raqa V0ycfJlE3eTprsS9bV7plvSkSZ7suja7XE+xfhYJlAYp08QaF2I5SH3ANkzK/cNFui+N AMzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5DXDICv1BrxMLav/y/sfl9xCxyyzw1drlgwbHD31nnY=; b=PUGgYQAstc5fyotkJaZfMJaJJ+s/qs2sTY+mzwwGSWfZyJyUyXmcBCzkFL7bEL9qxB zFG1wrVnhzHe2J+dNq0GwmFLm8PkqIv2+9zlfprtPyxCS8W4/f9fEm7DgcMmsOrxfN4h yGKskArIoUnCNJ3SnFx6zOGCkpaEnYkjGfV5iJXe8Eln48mvSb+iOaeBhJgXDcB81qK2 uPdUGC1+qoFwJ2Ld1+zO/RNLAXhprAxsUsa6fO3ePM+3inVlI3HFpkFAJjUEwZkMqmx5 FxjCo5l/1GqCX/LeqU2zEGv04ZZh7st+IeVQ2IYS1OXo4nxJnFq2hkMEggit6Hgd0byC Hvog== X-Gm-Message-State: APjAAAXlk6K0WGD+RCn3I1wvbuR6ohyzgYO+/Q1MsW44t5KujdagoILC RFOo8Wg/Vf86EjqXIAfeXV47LNraaF7WIU0DpixA2A== X-Google-Smtp-Source: APXvYqyiqxKyVbkEVFmDCthHWZQr49t/vJ4HZGux1rVCJ7ndOOvolG1P3fk1rEx5g5l1l+wu/M/J8MojP//24p2Kwrk= X-Received: by 2002:a63:5516:: with SMTP id j22mr136267pgb.201.1571259886189; Wed, 16 Oct 2019 14:04:46 -0700 (PDT) MIME-Version: 1.0 References: <291f012c-0ffd-599e-0dac-a6b4e05ebb97@infradead.org> In-Reply-To: <291f012c-0ffd-599e-0dac-a6b4e05ebb97@infradead.org> From: Brendan Higgins Date: Wed, 16 Oct 2019 14:04:35 -0700 Message-ID: Subject: Re: kunit.py should default to --build_dir=.kunit To: Randy Dunlap Cc: "Theodore Ts'o" , "open list:KERNEL SELFTEST FRAMEWORK" , KUnit Development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kselftest-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org On Fri, Oct 11, 2019 at 7:56 AM Randy Dunlap wrote: > > On 10/11/19 4:19 AM, Brendan Higgins wrote: > > +open list:KERNEL SELFTEST FRAMEWORK In case anyone in kselftest has > > any thoughts. > > > > On Thu, Oct 10, 2019 at 7:05 PM Theodore Ts'o = wrote: > >> > >> I've been experimenting with the ext4 kunit test case, and something t= hat would be really helpful is if the default is to store the object files = for the ARCM=3Dum kernel and its .config file in the top-level directory .k= unit. That is, that the default for --build_dir should be .kunit. > >> > >> Why does this important? Because the kernel developer will want to b= e running unit tests as well as building kernels that can be run under what= ever architecture they are normally developing for (for example, an x86 ker= nel that can be run using kvm; or a arm64 kernel that gets run on an Androi= d device by using the "fastboot" command). So that means we don't want to= be overwriting the object files and .config files for building the kernel = for x86 when building the kunit kernel using the um arch. For example, fo= r ext4, my ideal workflow might go something like this: > > > > That's a good point. > > > >> > >> % ./tools/testing/kunit/kunit.py run > >> > >> % kbuild > >> > >> % kvm-xfstests smoke > >> > >> > >> The point is when I'm developing an ext4 feature, or reviewing and mer= ging ext4 commits, I need to be able to maintain separate build trees and s= eparate config files for ARCH=3Dum as well as ARCH=3Dx86_64, and if the ARC= H=3Dum are stored in the kernel sources, then building with O=3D... doesn't= work: > >> > >> {/usr/projects/linux/kunit} (kunit) > >> 1084% make O=3D/build/test-dir > >> make[1]: Entering directory '/build/test-dir' > >> *** > >> *** The source tree is not clean, please run 'make mrproper' > >> *** in /usr/projects/linux/kunit > >> *** > > > > Should we maybe drop `--build_dir` in favor of `O`? > > Yes, preferably be consistent with the rest of the kernel makefiles. Alright, probably a good idea to make this change fairly soon then before we have to worry about backwards compatibility and such.