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 7272DC433F5 for ; Mon, 28 Mar 2022 19:36:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343518AbiC1TiK (ORCPT ); Mon, 28 Mar 2022 15:38:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36436 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245744AbiC1Th6 (ORCPT ); Mon, 28 Mar 2022 15:37:58 -0400 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BC8F64E391 for ; Mon, 28 Mar 2022 12:36:16 -0700 (PDT) Received: by mail-ej1-x630.google.com with SMTP id bg10so30806043ejb.4 for ; Mon, 28 Mar 2022 12:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y3nSgxmmg//mySu9Cydedpr4Jhc1g8g4FNQinYIPgOU=; b=T6fqFffdtdfHXtp2UxqFYdjmnVqBqs3TDGX0S+zhlL0s2VPk2tjDZHu/hwv5GitnER kOmO/z8a3ZFLZIZpaWjszZ5EkgGSPco6C/G1DP6st3I57A+o7HXj+mMmojdPN4OABjUa a0ZwIyskZwiNEvLAnPVakxU5R1wtxIVnHVhepPkynKyp7rlSwzzCPMb5t5pSaC8x4B2K bQejuXPF9k3ZteDBU7YMWoRzW0yIBmPY3Q7ZUNfg2YFHfrtf+/Ya3TLibn5BJ2daoycQ Aby/RloMJT4qVDAL/1CEzZVotkyGWjHCMBpBXmL+S1pN0R3CuGaiSM3DsPv+U2Hs2tAf xzbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y3nSgxmmg//mySu9Cydedpr4Jhc1g8g4FNQinYIPgOU=; b=0ed2jyQSpxkVeJ2K1yHdOu5j0gsQyfKg7E4TlZofSTPXUFmobEji/NeNzJ5hI5EnXA XBQA3CDP726J4yFMU3TTy7KnP8YAV3+Q6CRoH0b9aZ+OI/vfgBh6Y9UKPob2xNrnPX+s ZKz+OypJiRNB4hBYLz8YGV5jCK+eTKQEm++zoXlFnATDR7PwSCp+n5GO6kNyvvZs1mj7 k0i1hM3BeiTBJXbU1B/3/9qrdz2k7KShE2SHFtfVZLGLmdTY839IkXT0f4mnqQaNSxWI bTbSfQU9eBj6sFfSFvnEnVyoeZSwPB5eG41agOsylt6su9KbQvHffLyF2BMI83HFzD4O lWcw== X-Gm-Message-State: AOAM5339y3/F9EO0R2WFZlYc/8QH+M/NjYx51JBrSgnIqqSffPnrCSOa H+p2PAw6i7wpOnyuLPo0FwzPfdv739pBKzFcgeOMBg== X-Google-Smtp-Source: ABdhPJyRXH6t65V981NP8WK54X384Pl7tl7sgr87i7dlNrc6CVNo5L/KZ3rpYjK+gaACLnE+fpkP6az2xsOA+g5ryN8= X-Received: by 2002:a17:906:37cd:b0:6e0:bdb6:f309 with SMTP id o13-20020a17090637cd00b006e0bdb6f309mr18431848ejc.394.1648496174928; Mon, 28 Mar 2022 12:36:14 -0700 (PDT) MIME-Version: 1.0 References: <20220326003356.487828-1-dlatypov@google.com> In-Reply-To: From: Brendan Higgins Date: Mon, 28 Mar 2022 15:36:04 -0400 Message-ID: Subject: Re: [PATCH] Documentation: kunit: update kconfig options needed for UML coverage To: Daniel Latypov Cc: David Gow , Kees Cook , Linux Kernel Mailing List , KUnit Development , "open list:KERNEL SELFTEST FRAMEWORK" , Shuah Khan , maxime@cerno.tech Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 28, 2022 at 2:58 PM 'Daniel Latypov' via KUnit Development wrote: > > On Mon, Mar 28, 2022 at 11:54 AM 'Brendan Higgins' via KUnit > Development wrote: > > > > On Mon, Mar 28, 2022 at 12:35 PM Daniel Latypov wrote: > > > > > > On Fri, Mar 25, 2022 at 9:56 PM David Gow wrote: > > > > > > > > > > > > > > > > > > # Append coverage options to the current config > > > > > - $ echo -e "CONFIG_DEBUG_KERNEL=y\nCONFIG_DEBUG_INFO=y\nCONFIG_GCOV=y" >> .kunit/.kunitconfig > > > > > + $ echo -e "CONFIG_DEBUG_KERNEL=y\nCONFIG_DEBUG_INFO=y\nCONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y\nCONFIG_GCOV=y" >> .kunit/.kunitconfig > > > > > $ ./tools/testing/kunit/kunit.py run > > > > > > > > Would we want to instead use a chain of --kconfig_add arguments? (I > > > > think there are advantages either way...) > > > > > > I've been considering this ever since the --kconfig_add patch was accepted. > > > It's more compatible w/ commands using --kunitconfig, but it also > > > looks very verbose. > > > E.g. it looks like > > > > > > $ tools/testing/kunit/kunit.py run --make_options=CC=/usr/bin/gcc-6 > > > --kconfig_add=CONFIG_DEBUG_INFO=y > > > --kconfig_add=CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y > > > --kconfig_add=CONFIG_GCOV=y > > > > I don't think it's *that* much more verbose, but I see your point. I > > personally prefer this, but not enough to argue about it. > > I personally prefer it too, but I'm biased as the person who added > --kconfig_add. > They're both ugly enough I'd figured I'd save the bikeshedding for > another patch. > > > > > > Neither looks very appealing to me, so I've just kept it as-is for now. > > > > > > Maybe there's something we can do to make this easier (e.g. allowing > > > --kunitconfig to be repeated and mergable)? > > > > I would like --kunitconfig to be repeadable and mergable. > > Ack. > There's some things to consider first. I wasn't saying I want you to do it now. I just like the idea. > 1. This will conflict w/ > https://patchwork.kernel.org/project/linux-kselftest/patch/20220226212325.2984807-1-dlatypov@google.com/, > so I'm going to wait until that gets merged first. Agreed. > 2. some kconfigs can be incompatible (e.g. these options only work on > UML, can't combine w/ a non-UML compatible file) > How do we make this less of a footgun? > We'd talked about how it'd be nice if kconfig/"make olddefconfig" > could print out *why* options get dropped (either they're not visible, > have unmet deps, etc.). If we had that, I'd feel more comfortable w/ > repeatable kunitconfig. Good point. Something to think about. > 3. People have the ability to do this already if they're really sure it's safe > $ cat | ./tools/testing/kunit/kunit.py run --kunitconfig=/dev/stdin Sure, but I still think multiple --kunitconfig s would be a good feature to add. I think it makes it a bit easier to think about mixing and matching kunitconfigs. > 4. are we committed to supporting a "uml_coverage.kunitconfig" file? > As shown by the existence of this patch, we've let it get broken for a > bit, at least against linux-next (afaik, it was working on > torvalds/master up until the 5.18 window opened and we had some > patches reworking CONFIG_DEBUG_INFO). Good point. I don't think we want to get in that business. UML Coverage needs a lot of work, and I don't think we have the time or resources to own that work by ourselves. If someone else wants to add - and then own - such a kunitconfig, I would fully support them and maybe even help them a bit, but I don't want to own such a file until UML coverage gets a bit more stable. > These instructions exist so others don't have to try and re-figure out > the steps/workarounds. > But they're not more formally "part of KUnit" since no one has had the > expertise to maintain it (and fix issues like the reliance on gcc-6), > etc. > > Creating a kunitconfig file for this will further imply ownership. Agreed.