From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id D5E6121256BC8 for ; Wed, 8 May 2019 18:45:08 -0700 (PDT) Date: Wed, 8 May 2019 21:44:07 -0400 From: "Theodore Ts'o" Subject: Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework Message-ID: <20190509014407.GA7031@mit.edu> 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-Disposition: inline In-Reply-To: <4d963cdc-1cbb-35a3-292c-552f865ed1f7@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Frank Rowand Cc: pmladek@suse.com, linux-doc@vger.kernel.org, amir73il@gmail.com, Brendan Higgins , dri-devel@lists.freedesktop.org, Alexander.Levin@microsoft.com, mpe@ellerman.id.au, linux-kselftest@vger.kernel.org, shuah@kernel.org, robh@kernel.org, linux-nvdimm@lists.01.org, khilman@baylibre.com, knut.omang@oracle.com, kieran.bingham@ideasonboard.com, wfg@linux.intel.com, joel@jms.id.au, rientjes@google.com, jdike@addtoit.com, dan.carpenter@oracle.com, devicetree@vger.kernel.org, linux-kbuild@vger.kernel.org, Tim.Bird@sony.com, linux-um@lists.infradead.org, rostedt@goodmis.org, julia.lawall@lip6.fr, kunit-dev@googlegroups.com, richard@nod.at, sboyd@kernel.org, Greg KH , linux-kernel@vger.kernel.org, mcgrof@kernel.org, daniel@ffwll.ch, keescook@google.com, linux-fsdevel@vger.kernel.org List-ID: 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 _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm 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=ham 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 0DA6DC04A6B for ; Thu, 9 May 2019 01:45:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DCAAF21019 for ; Thu, 9 May 2019 01:45:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726730AbfEIBpo (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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Theodore Ts'o" Subject: Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework Date: Wed, 8 May 2019 21:44:07 -0400 Message-ID: <20190509014407.GA7031@mit.edu> 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-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <4d963cdc-1cbb-35a3-292c-552f865ed1f7-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" To: Frank Rowand Cc: pmladek-IBi9RG/b67k@public.gmane.org, linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, amir73il-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Brendan Higgins , dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, Alexander.Levin-0li6OtcxBFHby3iVrkZq2A@public.gmane.org, mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org, linux-kselftest-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, shuah-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org, khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org, knut.omang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, kieran.bingham-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org, wfg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org, joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org, rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, jdike-OPE4K8JWMJJBDgjK7y7TUQ@public.gmane.org, dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kbuild-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Tim.Bird-7U/KSKJipcs@public.gmane.org, linux-um-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org, julia.lawall-L2FTfq7BK8M@public.gmane.org, kunit-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, richard-/L3Ra7n9ekc@public.gmane.org, sboyd-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Greg KH , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, mcgrof-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, daniel-/w4YWyX8dFk@public.gmane.org, keescook-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: devicetree@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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 8 May 2019 21:44:07 -0400 Subject: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework In-Reply-To: <4d963cdc-1cbb-35a3-292c-552f865ed1f7@gmail.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> Message-ID: <20190509014407.GA7031@mit.edu> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: tytso@mit.edu (Theodore Ts'o) Date: Wed, 8 May 2019 21:44:07 -0400 Subject: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework In-Reply-To: <4d963cdc-1cbb-35a3-292c-552f865ed1f7@gmail.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> Message-ID: <20190509014407.GA7031@mit.edu> Content-Type: text/plain; charset="UTF-8" Message-ID: <20190509014407._iJCho8Dl4kdkRj2MCxJcK4x3I15pByEF6fbq8P96Jk@z> On Wed, May 08, 2019@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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outgoing-auth-1.mit.edu ([18.9.28.11] helo=outgoing.mit.edu) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hOY7V-0001Cf-WF for linux-um@lists.infradead.org; Thu, 09 May 2019 01:45:18 +0000 Date: Wed, 8 May 2019 21:44:07 -0400 From: "Theodore Ts'o" Subject: Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework Message-ID: <20190509014407.GA7031@mit.edu> 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-Disposition: inline In-Reply-To: <4d963cdc-1cbb-35a3-292c-552f865ed1f7@gmail.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: Frank Rowand Cc: pmladek@suse.com, linux-doc@vger.kernel.org, amir73il@gmail.com, Brendan Higgins , dri-devel@lists.freedesktop.org, Alexander.Levin@microsoft.com, mpe@ellerman.id.au, linux-kselftest@vger.kernel.org, shuah@kernel.org, robh@kernel.org, linux-nvdimm@lists.01.org, khilman@baylibre.com, knut.omang@oracle.com, kieran.bingham@ideasonboard.com, wfg@linux.intel.com, joel@jms.id.au, rientjes@google.com, jdike@addtoit.com, dan.carpenter@oracle.com, devicetree@vger.kernel.org, linux-kbuild@vger.kernel.org, Tim.Bird@sony.com, linux-um@lists.infradead.org, rostedt@goodmis.org, julia.lawall@lip6.fr, dan.j.williams@intel.com, kunit-dev@googlegroups.com, richard@nod.at, sboyd@kernel.org, Greg KH , linux-kernel@vger.kernel.org, mcgrof@kernel.org, daniel@ffwll.ch, keescook@google.com, linux-fsdevel@vger.kernel.org, logang@deltatee.com 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 _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um