archive mirror
 help / color / mirror / Atom feed
From: Brendan Higgins <>
To: "Theodore Ts'o" <>,
Cc: KUnit Development <>
Subject: Re: should default to --build_dir=.kunit
Date: Fri, 11 Oct 2019 04:19:37 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

+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 that would be really helpful is if the default is to store the object files for the ARCM=um kernel and its .config file in the top-level directory .kunit.   That is, that the default for --build_dir should be .kunit.
> Why does this important?  Because  the kernel developer will want to be running unit tests as well as building kernels that can be run under whatever architecture they are normally developing for (for example, an x86 kernel that can be run using kvm; or a arm64 kernel that gets run on an Android 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, for ext4, my ideal workflow might go something like this:

That's a good point.

> <hack hack hack>
> % ./tools/testing/kunit/  run
> <watch to see that unit tests succeed, and since most of the object files have already been built for the kunit kernel in be stored in the .kunit directory, this will be fast, since only the modified files will need to be recompiled>
> % kbuild
> <this is a script that builds an x86 kernel in /build/ext4-64 that is designed to be run under either kvm or in a GCE VM; since the kunit object files are stored in /build/ext4-kunit, the pre-existing files when building for x86_64 haven't been disturbed, so this build is fast as well>
> % kvm-xfstests smoke
> <this will run xfstests using the kernel plucked from /build/ext-64, using kvm>
> The point is when I'm developing an ext4 feature, or reviewing and merging ext4 commits, I need to be able to maintain separate build trees and separate config files for ARCH=um as well as ARCH=x86_64, and if the ARCH=um are stored in the kernel sources, then building with O=... doesn't work:
> <tytso@lambda> {/usr/projects/linux/kunit}   (kunit)
> 1084% make O=/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`?

> One of the other reasons why it would be good to use --build_dir by default is that way, building with a separate O= build directory is regularly tested.   Right now, " --build_dir=" seems to be broken.

Good point.

> % ./tools/testing/kunit/ run --build_dir=/build/ext4-kunit
> Generating .config ...
> [22:04:12] Building KUnit Kernel ...
> /usr/projects/linux/kunit/arch/x86/um/user-offsets.c:20:10: fatal error: asm/syscalls_64.h: No such file or directory
>    20 | #include <asm/syscalls_64.h>
>       |          ^~~~~~~~~~~~~~~~~~~
> compilation terminated.
> (This appears to be an ARCH=um bug, not a kunit bug, though.)

Yeah, I encountered this before. Some file is not getting properly
cleaned up by `make mrproper`. It works if you do `git clean -fdx` (I
know that's not a real solution for most people). Nevertheless, it
sounds like we need to sit down and actually solve this problem since
it is affecting users now.

I think you make a compelling argument. Anyone else have any thoughts on this?

       reply	other threads:[~2019-10-11 11:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2019-10-11 11:19 ` Brendan Higgins [this message]
2019-10-11 14:56   ` should default to --build_dir=.kunit Randy Dunlap
2019-10-16 21:04     ` Brendan Higgins
2019-10-17 12:51       ` Theodore Y. Ts'o
2019-10-18 22:12         ` Brendan Higgins
     [not found]   ` <>
2019-10-16 21:02     ` Brendan Higgins
2019-10-18 12:43       ` Luis Chamberlain
2019-10-18 22:22         ` Brendan Higgins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).