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=-2.4 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=unavailable 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 6E7F5C04A6B for ; Thu, 9 May 2019 01:45:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4BEBC20675 for ; Thu, 9 May 2019 01:45:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726705AbfEIBpo (ORCPT ); Wed, 8 May 2019 21:45:44 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:43465 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725832AbfEIBpo (ORCPT ); Wed, 8 May 2019 21:45:44 -0400 Received: from callcc.thunk.org ([66.31.38.53]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x491i7RW019749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 May 2019 21:44:09 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 9759E420024; Wed, 8 May 2019 21:44:07 -0400 (EDT) Date: Wed, 8 May 2019 21:44:07 -0400 From: "Theodore Ts'o" To: Frank Rowand Cc: Greg KH , Brendan Higgins , keescook@google.com, kieran.bingham@ideasonboard.com, mcgrof@kernel.org, robh@kernel.org, sboyd@kernel.org, shuah@kernel.org, devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, kunit-dev@googlegroups.com, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-nvdimm@lists.01.org, linux-um@lists.infradead.org, Alexander.Levin@microsoft.com, Tim.Bird@sony.com, amir73il@gmail.com, dan.carpenter@oracle.com, dan.j.williams@intel.com, daniel@ffwll.ch, jdike@addtoit.com, joel@jms.id.au, julia.lawall@lip6.fr, khilman@baylibre.com, knut.omang@oracle.com, logang@deltatee.com, mpe@ellerman.id.au, pmladek@suse.com, richard@nod.at, rientjes@google.com, rostedt@goodmis.org, wfg@linux.intel.com Subject: Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework Message-ID: <20190509014407.GA7031@mit.edu> Mail-Followup-To: Theodore Ts'o , Frank Rowand , Greg KH , Brendan Higgins , keescook@google.com, kieran.bingham@ideasonboard.com, mcgrof@kernel.org, robh@kernel.org, sboyd@kernel.org, shuah@kernel.org, devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, kunit-dev@googlegroups.com, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-nvdimm@lists.01.org, linux-um@lists.infradead.org, Alexander.Levin@microsoft.com, Tim.Bird@sony.com, amir73il@gmail.com, dan.carpenter@oracle.com, dan.j.williams@intel.com, daniel@ffwll.ch, jdike@addtoit.com, joel@jms.id.au, julia.lawall@lip6.fr, khilman@baylibre.com, knut.omang@oracle.com, logang@deltatee.com, mpe@ellerman.id.au, pmladek@suse.com, richard@nod.at, rientjes@google.com, rostedt@goodmis.org, wfg@linux.intel.com References: <20190501230126.229218-1-brendanhiggins@google.com> <54940124-50df-16ec-1a32-ad794ee05da7@gmail.com> <20190507080119.GB28121@kroah.com> <20190507172256.GB5900@mit.edu> <4d963cdc-1cbb-35a3-292c-552f865ed1f7@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4d963cdc-1cbb-35a3-292c-552f865ed1f7@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Wed, May 08, 2019 at 05:58:49PM -0700, Frank Rowand wrote: > > If KUnit is added to the kernel, and a subsystem that I am submitting > code for has chosen to use KUnit instead of kselftest, then yes, I do > *have* to use KUnit if my submission needs to contain a test for the > code unless I want to convince the maintainer that somehow my case > is special and I prefer to use kselftest instead of KUnittest. That's going to be between you and the maintainer. Today, if you want to submit a substantive change to xfs or ext4, you're going to be asked to create test for that new feature using xfstests. It doesn't matter that xfstests isn't in the kernel --- if that's what is required by the maintainer. > > supposed to be a simple way to run a large number of small tests that > > for specific small components in a system. > > kselftest also supports running a subset of tests. That subset of tests > can also be a large number of small tests. There is nothing inherent > in KUnit vs kselftest in this regard, as far as I am aware. The big difference is that kselftests are driven by a C program that runs in userspace. Take a look at tools/testing/selftests/filesystem/dnotify_test.c it has a main(int argc, char *argv) function. In contrast, KUnit are fragments of C code which run in the kernel; not in userspace. This allows us to test internal functions inside complex file system (such as the block allocator in ext4) directly. This makes it *fundamentally* different from kselftest. Cheers, - Ted