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.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 4F70BC4360C for ; Sun, 6 Oct 2019 16:56:07 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 21B1720862 for ; Sun, 6 Oct 2019 16:56:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 21B1720862 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=mit.edu Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from new-ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 0A1C210FC3CA8; Sun, 6 Oct 2019 09:58:52 -0700 (PDT) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=18.9.28.11; helo=outgoing.mit.edu; envelope-from=tytso@mit.edu; receiver= 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 6D92E10FC3CA5 for ; Sun, 6 Oct 2019 09:58:49 -0700 (PDT) Received: from callcc.thunk.org (pool-72-93-95-157.bstnma.fios.verizon.net [72.93.95.157]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x96GsaNE023214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 6 Oct 2019 12:54:38 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id A922942088C; Sun, 6 Oct 2019 12:54:36 -0400 (EDT) Date: Sun, 6 Oct 2019 12:54:36 -0400 From: "Theodore Y. Ts'o" To: Brendan Higgins Subject: Re: [PATCH v18 00/19] kunit: introduce KUnit, the Linux kernel unit testing framework Message-ID: <20191006165436.GA29585@mit.edu> References: <56e2e1a7-f8fe-765b-8452-1710b41895bf@kernel.org> <20191004222714.GA107737@google.com> <20191004232955.GC12012@mit.edu> <63e59b0b-b51e-01f4-6359-a134a1f903fd@kernel.org> <544bdfcb-fb35-5008-ec94-8d404a08fd14@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Message-ID-Hash: A44TGG35L2F7O2Q2PTJMRZQK2YV5ND2O X-Message-ID-Hash: A44TGG35L2F7O2Q2PTJMRZQK2YV5ND2O X-MailFrom: tytso@mit.edu X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation CC: shuah , Linus Torvalds , Frank Rowand , Greg Kroah-Hartman , Josh Poimboeuf , Kees Cook , Kieran Bingham , Luis Chamberlain , Peter Zijlstra , Rob Herring , Stephen Boyd , Masahiro Yamada , devicetree , dri-devel , kunit-dev@googlegroups.com, "open list:DOCUMENTATION" , linux-fsdevel , Linux Kbuild mailing list , Linux Kernel Mailing List , "open list:KERNEL SELFTEST FRAMEWORK" , linux-nvdimm , linux-um@lists.infradead.org, Sasha Levin , "Bird, Timothy" , Amir Goldstein , Dan Carpenter , Daniel Vetter , Jeff Dike , Joel Stanley , Julia Lawall , Kevin Hilman , Knut Omang , Michael Ellerman , Petr Mladek , Randy Dunlap , Richard Weinberger , David Rientjes , Steven Rostedt , wfg@linux.intel.com X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Fri, Oct 04, 2019 at 06:18:04PM -0700, Brendan Higgins wrote: > > Let's talk about current state. Right now kunit is in linux-next and > > we want to add a few more tests. We will have to coordinate the effort. > > Once kunit get into mainline, then the need for this coordination goes > > down. > > Sure, I was just thinking that getting other people to write the tests > would be better. Since not only is it then useful to someone else, it > provides the best possible exercise of KUnit. Well, one thing we *can* do is if (a) if we can create a kselftest branch which we know is stable and won't change, and (b) we can get assurances that Linus *will* accept that branch during the next merge window, those subsystems which want to use kself test can simply pull it into their tree. We've done this before in the file system world, when there has been some common set of changes needed to improve, say, Direct I/O, where the changes are put into a standalone branch, say, in the xfs tree, and those file systems which need it as a building block can pull it into their tree, and then add the changes needed to use those changes into their file system git tree. These changes are generally not terribly controversial, and we've not had to worry about people want to bikeshed the changes. There is a risk with doing this of course, which is that if the branch *is* controversial, or gets bike-shedded for some reason, then Linus gets upset and any branches which depended on said branch will get rejected at the next merge window. Which is the requirement for (a) and (b) above. Presumably, the fact that people were unwilling to let Kunit land during this merge window might will *because* we think more changes might be pending? The other thing I suppose I can do is to let the ext4 kunit tests land in ext4 tree, but with the necessary #ifdef's around things like "#include " so that the build won't blow up w/o kunit changes being in the tree that I'm building. It means I won't be able to run the tests without creating a test integration branch and merging in kunit by hand, which will super-annoying, of course. And if some of the bike-shedding is in Kunit's interfaces, then that becomes problematic as well, since any tests that are in ext4.git tree might change if people want to rename Kunit's publically exported functions (for example). > Hey Ted, do you know if that ext4 timestamp test can go in through > linux-kselftest? It seemed fairly self-contained. Or is that what you > were saying wouldn't work for you? Well, I was hoping that we might start creating more tests beyond just the ext4 timestamp tests.... - Ted _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org