From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-6.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=unavailable autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id ABF857D2EF for ; Wed, 15 May 2019 04:30:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725953AbfEOEaq (ORCPT ); Wed, 15 May 2019 00:30:46 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:47192 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725941AbfEOEaq (ORCPT ); Wed, 15 May 2019 00:30:46 -0400 Received: from callcc.thunk.org (168-215-239-3.static.ctl.one [168.215.239.3] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4F4SdqA023241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 May 2019 00:28:43 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 8480F420024; Wed, 15 May 2019 00:28:38 -0400 (EDT) Date: Wed, 15 May 2019 00:28:38 -0400 From: "Theodore Ts'o" To: Frank Rowand Cc: Tim.Bird@sony.com, knut.omang@oracle.com, gregkh@linuxfoundation.org, brendanhiggins@google.com, 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, 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, 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: <20190515042838.GA26954@mit.edu> Mail-Followup-To: Theodore Ts'o , Frank Rowand , Tim.Bird@sony.com, knut.omang@oracle.com, gregkh@linuxfoundation.org, brendanhiggins@google.com, 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, 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, logang@deltatee.com, mpe@ellerman.id.au, pmladek@suse.com, richard@nod.at, rientjes@google.com, rostedt@goodmis.org, wfg@linux.intel.com References: <580e092f-fa4e-eedc-9e9a-a57dd085f0a6@gmail.com> <20190509032017.GA29703@mit.edu> <7fd35df81c06f6eb319223a22e7b93f29926edb9.camel@oracle.com> <20190509133551.GD29703@mit.edu> <875c546d-9713-bb59-47e4-77a1d2c69a6d@gmail.com> <20190509214233.GA20877@mit.edu> <80c72e64-2665-bd51-f78c-97f50f9a53ba@gmail.com> <20190511173344.GA8507@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Tue, May 14, 2019 at 05:26:47PM -0700, Frank Rowand wrote: > On 5/11/19 10:33 AM, Theodore Ts'o wrote: > > On Fri, May 10, 2019 at 02:12:40PM -0700, Frank Rowand wrote: > >> However, the reply is incorrect. Kselftest in-kernel tests (which > >> is the context here) can be configured as built in instead of as > >> a module, and built in a UML kernel. The UML kernel can boot, > >> running the in-kernel tests before UML attempts to invoke the > >> init process. > > > > Um, Citation needed? > > The paragraph that you quoted tells you exactly how to run a kselftest > in-kernel test in a UML kernel. Just to what that paragraph says. I didn't quote a paragraph. But I'll quote from it now: $ make -C tools/testing/selftests run_tests This runs the kselftest harness, *in userspace*. That means you have to have a root file system, and it's run after init has started, by default. You asserted that kselftests allows you to run modules before init has started. There is absolutely zero, cero, nada, zilch mentions of any of anything like that in Documentation/dev-tools/kselftests.rst > > There exists test modules in the kernel that run before the init > > scripts run --- but that's not strictly speaking part of kselftests, > > and do not have any kind of infrastructure. As noted, the > > kselftests_harness header file fundamentally assumes that you are > > running test code in userspace. > > You are ignoring the kselftest in-kernel tests. I'm talking specifically about what you have been *claiming* to be kselftest in-kernel tests above. And I'm asserting they are really not kselftests. They are just ad hoc tests that are run in kernel space, which, when compiled as modules, can be loaded by a kselftest shell script. You can certainly hook in these ad hoc in-kernel tests via kselftests --- but then they aren't run before init starts, because kselftests is inherently a userspace-driven system. If you build these tests (many of which existed before kselftests was merged) into the kernel such that they are run before init starts, without the kselftest harness, then they are not kselftests, by definition. Both in how they are run, and since many of these in-kernel tests predate the introduction of kselftests --- in some cases, by many years. > We are talking in circles. I'm done with this thread. Yes, that sounds like it would be best. - Ted From mboxrd@z Thu Jan 1 00:00:00 1970 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 15 May 2019 00:28:38 -0400 Subject: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework In-Reply-To: References: <580e092f-fa4e-eedc-9e9a-a57dd085f0a6@gmail.com> <20190509032017.GA29703@mit.edu> <7fd35df81c06f6eb319223a22e7b93f29926edb9.camel@oracle.com> <20190509133551.GD29703@mit.edu> <875c546d-9713-bb59-47e4-77a1d2c69a6d@gmail.com> <20190509214233.GA20877@mit.edu> <80c72e64-2665-bd51-f78c-97f50f9a53ba@gmail.com> <20190511173344.GA8507@mit.edu> Message-ID: <20190515042838.GA26954@mit.edu> On Tue, May 14, 2019 at 05:26:47PM -0700, Frank Rowand wrote: > On 5/11/19 10:33 AM, Theodore Ts'o wrote: > > On Fri, May 10, 2019 at 02:12:40PM -0700, Frank Rowand wrote: > >> However, the reply is incorrect. Kselftest in-kernel tests (which > >> is the context here) can be configured as built in instead of as > >> a module, and built in a UML kernel. The UML kernel can boot, > >> running the in-kernel tests before UML attempts to invoke the > >> init process. > > > > Um, Citation needed? > > The paragraph that you quoted tells you exactly how to run a kselftest > in-kernel test in a UML kernel. Just to what that paragraph says. I didn't quote a paragraph. But I'll quote from it now: $ make -C tools/testing/selftests run_tests This runs the kselftest harness, *in userspace*. That means you have to have a root file system, and it's run after init has started, by default. You asserted that kselftests allows you to run modules before init has started. There is absolutely zero, cero, nada, zilch mentions of any of anything like that in Documentation/dev-tools/kselftests.rst > > There exists test modules in the kernel that run before the init > > scripts run --- but that's not strictly speaking part of kselftests, > > and do not have any kind of infrastructure. As noted, the > > kselftests_harness header file fundamentally assumes that you are > > running test code in userspace. > > You are ignoring the kselftest in-kernel tests. I'm talking specifically about what you have been *claiming* to be kselftest in-kernel tests above. And I'm asserting they are really not kselftests. They are just ad hoc tests that are run in kernel space, which, when compiled as modules, can be loaded by a kselftest shell script. You can certainly hook in these ad hoc in-kernel tests via kselftests --- but then they aren't run before init starts, because kselftests is inherently a userspace-driven system. If you build these tests (many of which existed before kselftests was merged) into the kernel such that they are run before init starts, without the kselftest harness, then they are not kselftests, by definition. Both in how they are run, and since many of these in-kernel tests predate the introduction of kselftests --- in some cases, by many years. > We are talking in circles. I'm done with this thread. Yes, that sounds like it would be best. - Ted From mboxrd@z Thu Jan 1 00:00:00 1970 From: tytso@mit.edu (Theodore Ts'o) Date: Wed, 15 May 2019 00:28:38 -0400 Subject: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework In-Reply-To: References: <580e092f-fa4e-eedc-9e9a-a57dd085f0a6@gmail.com> <20190509032017.GA29703@mit.edu> <7fd35df81c06f6eb319223a22e7b93f29926edb9.camel@oracle.com> <20190509133551.GD29703@mit.edu> <875c546d-9713-bb59-47e4-77a1d2c69a6d@gmail.com> <20190509214233.GA20877@mit.edu> <80c72e64-2665-bd51-f78c-97f50f9a53ba@gmail.com> <20190511173344.GA8507@mit.edu> Message-ID: <20190515042838.GA26954@mit.edu> Content-Type: text/plain; charset="UTF-8" Message-ID: <20190515042838.sHpvCjil7ybOP5Ka3fg3NENCKq5rBlaW3kFN2e9yRxE@z> On Tue, May 14, 2019@05:26:47PM -0700, Frank Rowand wrote: > On 5/11/19 10:33 AM, Theodore Ts'o wrote: > > On Fri, May 10, 2019@02:12:40PM -0700, Frank Rowand wrote: > >> However, the reply is incorrect. Kselftest in-kernel tests (which > >> is the context here) can be configured as built in instead of as > >> a module, and built in a UML kernel. The UML kernel can boot, > >> running the in-kernel tests before UML attempts to invoke the > >> init process. > > > > Um, Citation needed? > > The paragraph that you quoted tells you exactly how to run a kselftest > in-kernel test in a UML kernel. Just to what that paragraph says. I didn't quote a paragraph. But I'll quote from it now: $ make -C tools/testing/selftests run_tests This runs the kselftest harness, *in userspace*. That means you have to have a root file system, and it's run after init has started, by default. You asserted that kselftests allows you to run modules before init has started. There is absolutely zero, cero, nada, zilch mentions of any of anything like that in Documentation/dev-tools/kselftests.rst > > There exists test modules in the kernel that run before the init > > scripts run --- but that's not strictly speaking part of kselftests, > > and do not have any kind of infrastructure. As noted, the > > kselftests_harness header file fundamentally assumes that you are > > running test code in userspace. > > You are ignoring the kselftest in-kernel tests. I'm talking specifically about what you have been *claiming* to be kselftest in-kernel tests above. And I'm asserting they are really not kselftests. They are just ad hoc tests that are run in kernel space, which, when compiled as modules, can be loaded by a kselftest shell script. You can certainly hook in these ad hoc in-kernel tests via kselftests --- but then they aren't run before init starts, because kselftests is inherently a userspace-driven system. If you build these tests (many of which existed before kselftests was merged) into the kernel such that they are run before init starts, without the kselftest harness, then they are not kselftests, by definition. Both in how they are run, and since many of these in-kernel tests predate the introduction of kselftests --- in some cases, by many years. > We are talking in circles. I'm done with this thread. Yes, that sounds like it would be best. - Ted 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 0963D21276B97 for ; Tue, 14 May 2019 21:29:51 -0700 (PDT) Date: Wed, 15 May 2019 00:28:38 -0400 From: "Theodore Ts'o" Subject: Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework Message-ID: <20190515042838.GA26954@mit.edu> References: <580e092f-fa4e-eedc-9e9a-a57dd085f0a6@gmail.com> <20190509032017.GA29703@mit.edu> <7fd35df81c06f6eb319223a22e7b93f29926edb9.camel@oracle.com> <20190509133551.GD29703@mit.edu> <875c546d-9713-bb59-47e4-77a1d2c69a6d@gmail.com> <20190509214233.GA20877@mit.edu> <80c72e64-2665-bd51-f78c-97f50f9a53ba@gmail.com> <20190511173344.GA8507@mit.edu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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, brendanhiggins@google.com, 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, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, mcgrof@kernel.org, daniel@ffwll.ch, keescook@google.com, linux-fsdevel@vger.kernel.org List-ID: On Tue, May 14, 2019 at 05:26:47PM -0700, Frank Rowand wrote: > On 5/11/19 10:33 AM, Theodore Ts'o wrote: > > On Fri, May 10, 2019 at 02:12:40PM -0700, Frank Rowand wrote: > >> However, the reply is incorrect. Kselftest in-kernel tests (which > >> is the context here) can be configured as built in instead of as > >> a module, and built in a UML kernel. The UML kernel can boot, > >> running the in-kernel tests before UML attempts to invoke the > >> init process. > > > > Um, Citation needed? > > The paragraph that you quoted tells you exactly how to run a kselftest > in-kernel test in a UML kernel. Just to what that paragraph says. I didn't quote a paragraph. But I'll quote from it now: $ make -C tools/testing/selftests run_tests This runs the kselftest harness, *in userspace*. That means you have to have a root file system, and it's run after init has started, by default. You asserted that kselftests allows you to run modules before init has started. There is absolutely zero, cero, nada, zilch mentions of any of anything like that in Documentation/dev-tools/kselftests.rst > > There exists test modules in the kernel that run before the init > > scripts run --- but that's not strictly speaking part of kselftests, > > and do not have any kind of infrastructure. As noted, the > > kselftests_harness header file fundamentally assumes that you are > > running test code in userspace. > > You are ignoring the kselftest in-kernel tests. I'm talking specifically about what you have been *claiming* to be kselftest in-kernel tests above. And I'm asserting they are really not kselftests. They are just ad hoc tests that are run in kernel space, which, when compiled as modules, can be loaded by a kselftest shell script. You can certainly hook in these ad hoc in-kernel tests via kselftests --- but then they aren't run before init starts, because kselftests is inherently a userspace-driven system. If you build these tests (many of which existed before kselftests was merged) into the kernel such that they are run before init starts, without the kselftest harness, then they are not kselftests, by definition. Both in how they are run, and since many of these in-kernel tests predate the introduction of kselftests --- in some cases, by many years. > We are talking in circles. I'm done with this thread. Yes, that sounds like it would be best. - 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: 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 1hQlYD-0004eh-Kt for linux-um@lists.infradead.org; Wed, 15 May 2019 04:30:00 +0000 Date: Wed, 15 May 2019 00:28:38 -0400 From: "Theodore Ts'o" Subject: Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework Message-ID: <20190515042838.GA26954@mit.edu> References: <580e092f-fa4e-eedc-9e9a-a57dd085f0a6@gmail.com> <20190509032017.GA29703@mit.edu> <7fd35df81c06f6eb319223a22e7b93f29926edb9.camel@oracle.com> <20190509133551.GD29703@mit.edu> <875c546d-9713-bb59-47e4-77a1d2c69a6d@gmail.com> <20190509214233.GA20877@mit.edu> <80c72e64-2665-bd51-f78c-97f50f9a53ba@gmail.com> <20190511173344.GA8507@mit.edu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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, brendanhiggins@google.com, 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, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, mcgrof@kernel.org, daniel@ffwll.ch, keescook@google.com, linux-fsdevel@vger.kernel.org, logang@deltatee.com On Tue, May 14, 2019 at 05:26:47PM -0700, Frank Rowand wrote: > On 5/11/19 10:33 AM, Theodore Ts'o wrote: > > On Fri, May 10, 2019 at 02:12:40PM -0700, Frank Rowand wrote: > >> However, the reply is incorrect. Kselftest in-kernel tests (which > >> is the context here) can be configured as built in instead of as > >> a module, and built in a UML kernel. The UML kernel can boot, > >> running the in-kernel tests before UML attempts to invoke the > >> init process. > > > > Um, Citation needed? > > The paragraph that you quoted tells you exactly how to run a kselftest > in-kernel test in a UML kernel. Just to what that paragraph says. I didn't quote a paragraph. But I'll quote from it now: $ make -C tools/testing/selftests run_tests This runs the kselftest harness, *in userspace*. That means you have to have a root file system, and it's run after init has started, by default. You asserted that kselftests allows you to run modules before init has started. There is absolutely zero, cero, nada, zilch mentions of any of anything like that in Documentation/dev-tools/kselftests.rst > > There exists test modules in the kernel that run before the init > > scripts run --- but that's not strictly speaking part of kselftests, > > and do not have any kind of infrastructure. As noted, the > > kselftests_harness header file fundamentally assumes that you are > > running test code in userspace. > > You are ignoring the kselftest in-kernel tests. I'm talking specifically about what you have been *claiming* to be kselftest in-kernel tests above. And I'm asserting they are really not kselftests. They are just ad hoc tests that are run in kernel space, which, when compiled as modules, can be loaded by a kselftest shell script. You can certainly hook in these ad hoc in-kernel tests via kselftests --- but then they aren't run before init starts, because kselftests is inherently a userspace-driven system. If you build these tests (many of which existed before kselftests was merged) into the kernel such that they are run before init starts, without the kselftest harness, then they are not kselftests, by definition. Both in how they are run, and since many of these in-kernel tests predate the introduction of kselftests --- in some cases, by many years. > We are talking in circles. I'm done with this thread. Yes, that sounds like it would be best. - Ted _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um 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, 15 May 2019 00:28:38 -0400 Message-ID: <20190515042838.GA26954@mit.edu> References: <580e092f-fa4e-eedc-9e9a-a57dd085f0a6@gmail.com> <20190509032017.GA29703@mit.edu> <7fd35df81c06f6eb319223a22e7b93f29926edb9.camel@oracle.com> <20190509133551.GD29703@mit.edu> <875c546d-9713-bb59-47e4-77a1d2c69a6d@gmail.com> <20190509214233.GA20877@mit.edu> <80c72e64-2665-bd51-f78c-97f50f9a53ba@gmail.com> <20190511173344.GA8507@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Frank Rowand Cc: pmladek@suse.com, linux-doc@vger.kernel.org, amir73il@gmail.com, brendanhiggins@google.com, dri-devel@lists.freedesktop.org, Alexander.Levin@microsoft.com, mpe@ellerman.id.au, linux-kselftest@vger.kernel.org, shuah@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, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, mcgrof@kernel.org, keescook@google.com, linux-fsdevel@vger.kernel.org, logang@deltatee.com List-Id: devicetree@vger.kernel.org T24gVHVlLCBNYXkgMTQsIDIwMTkgYXQgMDU6MjY6NDdQTSAtMDcwMCwgRnJhbmsgUm93YW5kIHdy b3RlOgo+IE9uIDUvMTEvMTkgMTA6MzMgQU0sIFRoZW9kb3JlIFRzJ28gd3JvdGU6Cj4gPiBPbiBG cmksIE1heSAxMCwgMjAxOSBhdCAwMjoxMjo0MFBNIC0wNzAwLCBGcmFuayBSb3dhbmQgd3JvdGU6 Cj4gPj4gSG93ZXZlciwgdGhlIHJlcGx5IGlzIGluY29ycmVjdC4gIEtzZWxmdGVzdCBpbi1rZXJu ZWwgdGVzdHMgKHdoaWNoCj4gPj4gaXMgdGhlIGNvbnRleHQgaGVyZSkgY2FuIGJlIGNvbmZpZ3Vy ZWQgYXMgYnVpbHQgaW4gaW5zdGVhZCBvZiBhcwo+ID4+IGEgbW9kdWxlLCBhbmQgYnVpbHQgaW4g YSBVTUwga2VybmVsLiAgVGhlIFVNTCBrZXJuZWwgY2FuIGJvb3QsCj4gPj4gcnVubmluZyB0aGUg aW4ta2VybmVsIHRlc3RzIGJlZm9yZSBVTUwgYXR0ZW1wdHMgdG8gaW52b2tlIHRoZQo+ID4+IGlu aXQgcHJvY2Vzcy4KPiA+IAo+ID4gVW0sIENpdGF0aW9uIG5lZWRlZD8KPiAKPiBUaGUgcGFyYWdy YXBoIHRoYXQgeW91IHF1b3RlZCB0ZWxscyB5b3UgZXhhY3RseSBob3cgdG8gcnVuIGEga3NlbGZ0 ZXN0Cj4gaW4ta2VybmVsIHRlc3QgaW4gYSBVTUwga2VybmVsLiAgSnVzdCB0byB3aGF0IHRoYXQg cGFyYWdyYXBoIHNheXMuCgpJIGRpZG4ndCBxdW90ZSBhIHBhcmFncmFwaC4gIEJ1dCBJJ2xsIHF1 b3RlIGZyb20gaXQgbm93OgoKICAkIG1ha2UgLUMgdG9vbHMvdGVzdGluZy9zZWxmdGVzdHMgcnVu X3Rlc3RzCgpUaGlzIHJ1bnMgdGhlIGtzZWxmdGVzdCBoYXJuZXNzLCAqaW4gdXNlcnNwYWNlKi4g IFRoYXQgbWVhbnMgeW91IGhhdmUKdG8gaGF2ZSBhIHJvb3QgZmlsZSBzeXN0ZW0sIGFuZCBpdCdz IHJ1biBhZnRlciBpbml0IGhhcyBzdGFydGVkLCBieQpkZWZhdWx0LiAgWW91IGFzc2VydGVkIHRo YXQga3NlbGZ0ZXN0cyBhbGxvd3MgeW91IHRvIHJ1biBtb2R1bGVzCmJlZm9yZSBpbml0IGhhcyBz dGFydGVkLiAgVGhlcmUgaXMgYWJzb2x1dGVseSB6ZXJvLCBjZXJvLCBuYWRhLCB6aWxjaAptZW50 aW9ucyBvZiBhbnkgb2YgYW55dGhpbmcgbGlrZSB0aGF0IGluIERvY3VtZW50YXRpb24vZGV2LXRv b2xzL2tzZWxmdGVzdHMucnN0Cgo+ID4gVGhlcmUgZXhpc3RzIHRlc3QgbW9kdWxlcyBpbiB0aGUg a2VybmVsIHRoYXQgcnVuIGJlZm9yZSB0aGUgaW5pdAo+ID4gc2NyaXB0cyBydW4gLS0tIGJ1dCB0 aGF0J3Mgbm90IHN0cmljdGx5IHNwZWFraW5nIHBhcnQgb2Yga3NlbGZ0ZXN0cywKPiA+IGFuZCBk byBub3QgaGF2ZSBhbnkga2luZCBvZiBpbmZyYXN0cnVjdHVyZS4gIEFzIG5vdGVkLCB0aGUKPiA+ IGtzZWxmdGVzdHNfaGFybmVzcyBoZWFkZXIgZmlsZSBmdW5kYW1lbnRhbGx5IGFzc3VtZXMgdGhh dCB5b3UgYXJlCj4gPiBydW5uaW5nIHRlc3QgY29kZSBpbiB1c2Vyc3BhY2UuCj4gCj4gWW91IGFy ZSBpZ25vcmluZyB0aGUga3NlbGZ0ZXN0IGluLWtlcm5lbCB0ZXN0cy4KCkknbSB0YWxraW5nIHNw ZWNpZmljYWxseSBhYm91dCB3aGF0IHlvdSBoYXZlIGJlZW4gKmNsYWltaW5nKiB0byBiZQprc2Vs ZnRlc3QgaW4ta2VybmVsIHRlc3RzIGFib3ZlLiAgQW5kIEknbSBhc3NlcnRpbmcgdGhleSBhcmUg cmVhbGx5Cm5vdCBrc2VsZnRlc3RzLiAgVGhleSBhcmUganVzdCBhZCBob2MgdGVzdHMgdGhhdCBh cmUgcnVuIGluIGtlcm5lbApzcGFjZSwgd2hpY2gsIHdoZW4gY29tcGlsZWQgYXMgbW9kdWxlcywg Y2FuIGJlIGxvYWRlZCBieSBhIGtzZWxmdGVzdApzaGVsbCBzY3JpcHQuICBZb3UgY2FuIGNlcnRh aW5seSBob29rIGluIHRoZXNlIGFkIGhvYyBpbi1rZXJuZWwgdGVzdHMKdmlhIGtzZWxmdGVzdHMg LS0tIGJ1dCB0aGVuIHRoZXkgYXJlbid0IHJ1biBiZWZvcmUgaW5pdCBzdGFydHMsCmJlY2F1c2Ug a3NlbGZ0ZXN0cyBpcyBpbmhlcmVudGx5IGEgdXNlcnNwYWNlLWRyaXZlbiBzeXN0ZW0uCgpJZiB5 b3UgYnVpbGQgdGhlc2UgdGVzdHMgKG1hbnkgb2Ygd2hpY2ggZXhpc3RlZCBiZWZvcmUga3NlbGZ0 ZXN0cyB3YXMKbWVyZ2VkKSBpbnRvIHRoZSBrZXJuZWwgc3VjaCB0aGF0IHRoZXkgYXJlIHJ1biBi ZWZvcmUgaW5pdCBzdGFydHMsCndpdGhvdXQgdGhlIGtzZWxmdGVzdCBoYXJuZXNzLCB0aGVuIHRo ZXkgYXJlIG5vdCBrc2VsZnRlc3RzLCBieQpkZWZpbml0aW9uLiAgQm90aCBpbiBob3cgdGhleSBh cmUgcnVuLCBhbmQgc2luY2UgbWFueSBvZiB0aGVzZQppbi1rZXJuZWwgdGVzdHMgcHJlZGF0ZSB0 aGUgaW50cm9kdWN0aW9uIG9mIGtzZWxmdGVzdHMgLS0tIGluIHNvbWUKY2FzZXMsIGJ5IG1hbnkg eWVhcnMuCgo+IFdlIGFyZSB0YWxraW5nIGluIGNpcmNsZXMuICBJJ20gZG9uZSB3aXRoIHRoaXMg dGhyZWFkLgoKWWVzLCB0aGF0IHNvdW5kcyBsaWtlIGl0IHdvdWxkIGJlIGJlc3QuCgoJCQkJCQkt IFRlZApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmkt ZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6 Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWw=