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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 33663C433F5 for ; Sat, 2 Oct 2021 19:29:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0DA5561B06 for ; Sat, 2 Oct 2021 19:29:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233920AbhJBTbl (ORCPT ); Sat, 2 Oct 2021 15:31:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45918 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233894AbhJBTbd (ORCPT ); Sat, 2 Oct 2021 15:31:33 -0400 Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 364DEC0613EC for ; Sat, 2 Oct 2021 12:29:47 -0700 (PDT) Received: by mail-vk1-xa2c.google.com with SMTP id u66so126030vku.4 for ; Sat, 02 Oct 2021 12:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=9leNoau+R4yAyj8BW9BHEyz2KSOlgtqAoposPj8ZmQw=; b=Oedpzi0n93C5YwGDPoD3KcGVnay0KPYT0FLDCxr+XQ51SAn6i9L/G6FYTykc7os22a f4QVotgw+qjSgIOiMOEyaGh/biW+1TClN1PkjYMTxPAvj1yPopixUk2FZxBg5O4vWo0W S8Vn1aszWFaCT0LadyhHI9A7QsCQ/EOr/EDKW+eAk7kV/JzkoU+TeMh+k+knFJ1+B6s/ z0wKM7n2wTz4WUTH0uWfzwP2iHid2tTAPnJMyZb6N/uRX0g5j1wHXBab49fwWbqrjphq B4ylSxVEKBrLhzVlS+vBcmUdqOM2HCDGYh1c0+RkYwZKxVI9MGLeq9mdhq7JOtNMC0Qx zldA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=9leNoau+R4yAyj8BW9BHEyz2KSOlgtqAoposPj8ZmQw=; b=LIH+1jlrKfKBUPbjiMtuOjpgd8rmmqP3d3/HK5YM462Sivg4Z1CLd1kCTEBEIB33pb jaC3E72lWvknQSCrBBn+81qPcq0bfC/Jjvd5r9UBOxVOi3DXzp3lLAdy5YU8EnWKwSYR Impdd4+hQv6ZvJIz2HN6sZPOtd3MPbeelPYKlJ6aMCZrzRYyiVcr2g/K924TLXODJdeu fL2SR8X0UV2mfqyM5G7AZN1EWxbpyXyMKjw9R0QnbIOD+HQLyCOTOFI4+4eLMd61Fa1Z TwxguKiiq8EyMh7Xv91AvFqylCSoWfy30mRwEzRHcwxXKvJHqMOjr6qTr2ekKSk9kmQM ScIg== X-Gm-Message-State: AOAM530o0HaCkKxxIVU9Gynd250ZIfLZNWwXet6mE6hs7iMU7HGs0Oyi +/AiAA1ZluT2U6BHI/pFBfU= X-Google-Smtp-Source: ABdhPJwJTZrtzNGoCgRSF+WXPZ7c9CNC+maGpP0gHcYDwk0t4TFtsnuzc9z+3/PlkposVRX+j8vNAw== X-Received: by 2002:a1f:5ed4:: with SMTP id s203mr12760932vkb.20.1633202986342; Sat, 02 Oct 2021 12:29:46 -0700 (PDT) Received: from marsc.168.1.7 ([2804:30c:95c:7f00:4a55:391d:16ef:6119]) by smtp.gmail.com with ESMTPSA id d125sm4928962vkb.5.2021.10.02.12.29.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 Oct 2021 12:29:45 -0700 (PDT) Date: Sat, 2 Oct 2021 16:29:42 -0300 From: Marcelo Schmitt To: Daniel Latypov Cc: brendanhiggins@google.com, andersonreisrosa@gmail.com, linux-kernel@vger.kernel.org, kunit-dev@googlegroups.com Subject: Re: [PATCH] kunit: mock: add support for function mocks with no parameters Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Removed Andy from the CC list as we're not talking about that bug anymore. [...] > > > We can work on something else besides mocking if it makes more sense to the > > > project. > > > > Mocking doesn't feel like an area where we can expect to see progress right now. > > In terms of other KUnit features we know would be useful now, I think > > it's mostly just [1] and [2], which hopefully will land in 5.16. > > To be clear, if anyone thinks up a useful feature, that'd be great. > I personally am just out of ideas at the moment, and I think so are > Brendan and David. > > We'd want to prioritize features that can improve existing tests or > unblock known new tests. > Mocking in the alpha version of KUnit is a case where a feature > sounded really good on paper and had a bunch of bells and whistles > (e.g. strict/nice/naggy mocks support, etc.) but was perhaps > overengineered and thus failed to find a home upstream. > > But I just thought of a few more things we could do in the kunit.py script. > I think we have more room for improvement there than in the in-kernel > part of KUnit right now, but I assume it's the more boring part for > most people. > > One thing I'd really like to see is getting code coverage to work in > kunit.py while using QEMU. > We have a process for doing so under UML here: > https://lore.kernel.org/linux-kselftest/20210901190623.315736-1-rmoar@google.com/ > UML actually uses a different coverage implementation than normal, so > there's a few things that would need to change. > > We can build and run against "normal" coverage kernels pretty easily: > > $ cat >qemu_coverage_kunitconfig < CONFIG_KUNIT=y > CONFIG_KUNIT_EXAMPLE_TEST=y > CONFIG_GCOV_KERNEL=y > CONFIG_DEBUG_FS=y > CONFIG_GCOV_PROFILE_ALL=y > EOF > $ ./tools/testing/kunit/kunit.py run --arch=x86_64 > --kunitconfig=qemu_coverage_kunitconfig > > The problem is we'd need to copy the coverage data off the VM instead > of just letting it shutdown when tests are done. > If we had a userspace running, we'd basically do something like > $ scp -r user@vm:/sys/kernel/debug/gcov . > > > > Normal KUnit tests definitely don't want to have to have the overhead > of running a userspace, so the implementation might look like a > "--qemu_coverage" flag, or maybe a set of generic flags that would > give a user enough control over the VM to do this. > Or maybe the right answer is to not involve kunit.py at all. > > Not sure if that sounds interesting to you or anyone. > Sounds cool. We'll try to make it. Thanks > > > > I think right now we probably need more tests written to have a better > > idea of what else we could/should do. > > Partly because of that, David is trying to get the ball rolling on > > testing ext4. We're also hopeful that it'll be easier to add tests if > > adjacent code is already tested (sharing fakes, conventions, ability > > to copy-paste, etc.). > > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git/commit/?h=kunit&id=3b29021ddd10cfb6b2565c623595bd3b02036f33 > > [2] https://lore.kernel.org/linux-kselftest/20210909001037.2842954-1-dlatypov@google.com/ > > > >