Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 19 Dec 2022 16:27:10 -0800
From:   Dan Williams <dan.j.williams@intel.com>
To:     Luis Chamberlain <mcgrof@kernel.org>,
        Dan Williams <dan.j.williams@intel.com>
CC:     <alison.schofield@intel.com>, <vishal.l.verma@intel.com>,
        <ira.weiny@intel.com>, <bwidawsk@kernel.org>, <dave@stgolabs.net>,
        <a.manzanares@samsung.com>, <linux-cxl@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] cxl_test: upgrade as a first class citizen selftests
 capable driver
Message-ID: <63a1015e6ec4a_1bf22944c@dwillia2-xfh.jf.intel.com.notmuch>
References: <20221217034947.1174795-1-mcgrof@kernel.org>
 <639d4bb71bada_b41e329452@dwillia2-xfh.jf.intel.com.notmuch>
 <Y6DDPGnwszUAiNh2@bombadil.infradead.org>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Y6DDPGnwszUAiNh2@bombadil.infradead.org>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?yR4t+tkH5sdjZDFD9vrVEj8v4oII7hwFTf0ksOJ7AGUesW7pwXMts8wQ8FJ8?=
 =?us-ascii?Q?YtJGr/RR3FcFXTJOFH5xCBj8EDWRxWdgP4rs6bgjSfYXJVdRDDvPWdUvLmbb?=
 =?us-ascii?Q?0eMhv1PG5zfLelrdZjQqHO9d3fCcGzaJZcYvcyP1gf0z15SirSdkq2mP3a4p?=
 =?us-ascii?Q?mbn+ibWX2+Mv+XRcWS/RUeR2VB6OkjRdptQ4g7G/NV8Xa9TXLKgLhXgSK5xe?=
 =?us-ascii?Q?6N2QeYuh0UfNw+N0Xz26Z+XH14bDsfgXR0ReoxHVLBvrBG0zGATRyqzMjLPn?=
 =?us-ascii?Q?QsLTmhHpZJ7aBhWP7qtOAi8kk4UAaQtIi50cIgxuBJ7EfwXeB7nOcZalBcyG?=
 =?us-ascii?Q?e1W4Vhke6e3i+MfOTVuaVSpxchnLvguR1nHLFUz5DreMeEeA65kv/M2k/Vkc?=
 =?us-ascii?Q?XIQhkc15fYgn3CXCPKvM5664Af0/Ms9LznVZEWqmU0OPEi+Tc2TUR43kGJql?=
 =?us-ascii?Q?IgM+XMtbVjToQVP22o2+vUE14NKsPHXASy++YPbOswlkpzPwfdZhxrq71fb6?=
 =?us-ascii?Q?efLeuUYE7gWApAwm26gXU1f1x8FJr9l4jHFwzABxlIyMFjlJmtvChybdE7Oh?=
 =?us-ascii?Q?iuI3Z35uVEPtFevW3VGfdEGBj9ySkS5F3nylGAyY2g1eLrCW3FxDmsTw5Rwr?=
 =?us-ascii?Q?aPB9RfdP8KIWJW7fUWRSXUoG1jnPUDjnpPyh1PBpnp4Xnla8AeSuMWpjR3d/?=
 =?us-ascii?Q?gZgKYuyiSbGD/n+AfZrXhKEzx1VdjYo/8hasg6yBvyX620qonXxPTER3pm2W?=
 =?us-ascii?Q?lbxVejVuh7cbCy6nAzcX24m86ARnt1vC6+RidGSq16XVw24B9UvqBQ+ATaKL?=
 =?us-ascii?Q?jfEozUAEE8awLIQNk0TLyHkbB1m66FG/dFvlM4ldD2gl5f/fKMIpg71pXqCq?=
 =?us-ascii?Q?Urj50p9zc87d8rmPxbs3ZyjfetFZ4QcDCFv402m6PvdoOTMa85AkJaqZoPq+?=
 =?us-ascii?Q?J9BFANJK3AzqHiy3evm5LLLxFTGy3OH7KCX2kMngGZ5F47cwWvenH9y3LV62?=
 =?us-ascii?Q?L79yCg61m5VetWQAuDcVkzuU99Mfd/QJHyCiUbnEw96dK0BsfjiGaXTWVByI?=
 =?us-ascii?Q?fJ+5616ylQTYqc4kng91ZinPFN0LCBgfiZosyr6me6bKZWHEEjNLhjmdabjI?=
 =?us-ascii?Q?gKkE+v5nN5kZtzS0Y5sDimq73Ro3SH5WL/7hTi/c32csrMcnUsdGKyPfp2QY?=
 =?us-ascii?Q?2eXDjNQIXu31BxZD6O/cd11Pxghfp7SYNVdad+MDkBIs6BKnM5Q8/mqgU9iC?=
 =?us-ascii?Q?as4pg5ZNf4UOzsmRiQm3rwywxTPENcOw88TfIuXnhtts1uzG7J1j3IuuQjJ5?=
 =?us-ascii?Q?Y9E7AnPdhneJYDR8q06Pf3XjEVC4OzqBf4TbkyNVZMmz+rzMawXu3NRKOCi+?=
 =?us-ascii?Q?Cq15M2tAWk6glzxu1LXe24HpTiayeJKqT7dqN+CmEDt87qpil2flRvMZCJCr?=
 =?us-ascii?Q?a86zN3Udr3DwsjtT1H4w0k5Y6YPy7L12RQVegu1C5QGlES00Qo5Xrho4zlpo?=
 =?us-ascii?Q?LXjV35eIA86gf8+nSCYSbRlTq7ixbRdpEBAlTpSeLzpkMKPVbG6+fwTdzIFI?=
 =?us-ascii?Q?fXFUf++O3KTB5Sx1xi4FdBck/O+VH4fqVzu2GHAIvyybt2huGOmKEOVfGraw?=
 =?us-ascii?Q?RA=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 56e36756-d492-46af-228c-08dae220f0ae
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1101MB2126.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Dec 2022 00:27:13.4089
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 2WcHYOdm7Jc6s9gqa9na7R8NkHoahBP16m1o/3FdhjERS8g4gDvgL5wkcp+W9L0pdyfT0QbqqScpJcDjif16bFZ6OULTImWwPtjZak0eBLI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR11MB7332
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Luis Chamberlain wrote:
> On Fri, Dec 16, 2022 at 08:55:19PM -0800, Dan Williams wrote:
> > In other words the suggestion that the current
> > organization ultimately leads to bit rot has not been substantiated in
> > practice.
> 
> On top of this patch I just added a custom debug patch to my tree which
> enables CXL_BUS and CXL_TEST by default when this is currently allowed
> and it got quite a bit of kernel build warnings. Although some of these
> are specific to my change, some of them do not seem to be related to
> that and likely could benefit from fixing:
> 
> https://gist.github.com/mcgrof/73dce72939590c6edc9413b0384ae4c2
> 
> And so although you may not see some build warnings so far, it does not
> negate my suggestion that having cxl_test as a proper upstream driver strategy
> gets you more build testing / coverage.

If autobuild coverage of test components is the main concern then
cxl_test can copy what nfit_test is doing with CONFIG_NVDIMM_TEST_BUILD.
No need for disruptive redesign of how this facility is integrated.

> > The proposed direction to move tests out of the ndctl.git repo into the
> > kernel solves the wrong problem.
> 
> That's not in any way what I suggested and is not the point to my patch.
> 
> The proposed patch does not suggest to ditch ndctl unit tests but to
> *enable* also sefltests to make use of cxl_test using the selftests
> framework, which is very different. It is not saying "abandon" ndctl
> unit tests, but rather, "also enable linux kernel selftests for CXL with
> cxl_test".

I think centralizing test scripts is a virtue, and right now the
momentum is with those located ndctl.git. This is why I jumped to the
conclusion that the long term direction would be to pick one location
for maintainer regression tests.

> But more importantly, it looks for the value of proper kernel
> integration and making use of kconfig for the actual dependencies
> and requirements. This is of high value.
> 
> In addition to this, one possible area I see of value with this change is the
> ability to also use the wrap feature later, even without cxl_test to enable
> error injection. What would this look like? You simply replace one built in
> routine as you do with another which has sprinkled in should_fail() calls,
> which otherwise would be an eyesore upstream. This shold also then not
> depend the rest of cxl_test stuff, but can make use of building
> alternative wrap routines which could be replacement for upstream ones.
> 
> Another benefit of this strategy is you can also test cxl_test *without*
> the need for for requiring modules, which some folks prefer for testing.
> At LSFMM this came up for instance and one of the biggest grudges with
> testing some frameworks was the dependency on modules.

I do think this is the void that QEMU CXL testing would attempt to fill.