Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp109740ybl; Mon, 27 Jan 2020 23:21:02 -0800 (PST) X-Google-Smtp-Source: APXvYqwpc868666Z07B4kx13zCv2JbOictAUzI5MLxZGJK2L4DrxImuKBxRO9hBuPEA4BI54stkd X-Received: by 2002:aca:ddc2:: with SMTP id u185mr2043934oig.24.1580196062598; Mon, 27 Jan 2020 23:21:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580196062; cv=none; d=google.com; s=arc-20160816; b=rVLDdk7Ld2zTrqmitBxF0BveCeL8QTUUnZVS5zXY0CqtbVz9zv726HOqRur4kr+ie3 NF2w10yjYoN5pWssF2sfIGhtItFKHNytDZozbWvAIWzfwKpj3IGmUUnv5WMM3P49K4fd hR+DLmIOz1E7kWszdA0gS9ptLf0svApX/0pjvQyRO2py4E5jlTsO6PJN2ZpNfogj/PLc g0MsR0STMjz2TDjnMuCNy1jwzBC2qpXFNtM+MiuErhF+n374rqsp2yJApH+Y5htz0vKu uTh0yTxQ8z18T+kIQrRffAc4OTfdvfvcwaL6kiNo0oRqAv+cgYr5pCCmef5jeM03/gA4 qJpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=3k6NKPH7fR4pIU1iDhzXIE3sCOzlwL1ZN9ZIEkKxkCM=; b=mbw1ZK/eZLkmC7bbJFfmone8jh6P9DOPUknFaCbOWNSPQ2rFo6onmYWACsz/XhtVJo AxX56wN34Gu1NS37ez7XFBiuyodCheD14u7QIS78dd1YwRPXJbME9d8Wb3hE0hpXRU3e yyg8vZOkLWet0ww2H7xSylsYugxx04ff2ZnmDE+E4oT5uQ/TCiddgM4d5Dfe5OjtERuV b/zVqs0ZjSwMMnXtXYB71SOZNZMXEtkDW/EgqocrZUgaSuOQjfWoInX4MkiEbHUVIKEu DdHm8FHSYCUj8dbnKF3/gJOJQr711rVhi2fJ3Ke66ov+ycJ3xyI6qiinUKlwDFxkgF/B HHvA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=srujTkRl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z3si4250687oib.164.2020.01.27.23.20.47; Mon, 27 Jan 2020 23:21:02 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=srujTkRl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725853AbgA1HTj (ORCPT + 99 others); Tue, 28 Jan 2020 02:19:39 -0500 Received: from mail-pf1-f195.google.com ([209.85.210.195]:34762 "EHLO mail-pf1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725810AbgA1HTj (ORCPT ); Tue, 28 Jan 2020 02:19:39 -0500 Received: by mail-pf1-f195.google.com with SMTP id i6so6175267pfc.1 for ; Mon, 27 Jan 2020 23:19:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3k6NKPH7fR4pIU1iDhzXIE3sCOzlwL1ZN9ZIEkKxkCM=; b=srujTkRlXcMYfFAU4ajeK8XzFxdSFdtymlFDHFWwtjl6RYYdXfct49yGfp0R3Ft/Gk b21LQneptyAycuw/QTxfkxRds7UsDs0nOcvfIjhPf5kg6HG/fumf1p+SOyhPDP/nWgeP N5AwCoyysSHeNcp/4iev4K0SThnflmL0sS9bNw5CfETHliSa70QE6XwKZ6Bfqiixt3vq zSUjHO7HdXpF/GNVk0WVWL+Zc6eaGXSoDWtvFQJdB+9aFEzKZ4wrtQexneK+aEI716Ld KNu+IVGouW2wF3H1iVqEscIlzXyahFYpfZmS4xEkSoV7/uFbghBbqV5xBi32Vua8xClE x64Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3k6NKPH7fR4pIU1iDhzXIE3sCOzlwL1ZN9ZIEkKxkCM=; b=YY+kX0u1kfVOlLnnxUlRlHT/NZlwNj5brDEhCuNDLCeNlsAXlODLHlWCwYs1/Ti0D5 V9ySXzmdyNzTtJj5tNjrWkencwrildBlPtENAkaJWMJpD4L/9mjGsAFn4KQ/1qygYMt8 VEMar5oeBOWagrvBhOdHkfyrSHYdapKKFai3PwMQIWMkFgGdNaxCLpdDw1Phz+AF9qne KFLDmQF3qvsMngadKxiuRE/7RaV+pMjEIhfvrDE0yEwjIT860LR4sEiAXduUDohJJECI B8HEVrSYX8UCJxzeY/sZe2obnsnLop5r/2rurqpsyHNq72YNhTfkAA0JgOm248LYvss9 NzUQ== X-Gm-Message-State: APjAAAVC5yQ+arAZUrRUexQBeTGBHYXDwvtRAruEKLb68HGBDo0kbC+/ TBkg1dGkVgBCoOXzKDAYTaUMGY5chj7d3mCuvioFWA== X-Received: by 2002:a63:597:: with SMTP id 145mr22603404pgf.384.1580195978166; Mon, 27 Jan 2020 23:19:38 -0800 (PST) MIME-Version: 1.0 References: <20191216220555.245089-1-brendanhiggins@google.com> <20200106224022.GX11244@42.do-not-panic.com> <594b7815-0611-34ea-beb5-0642114b5d82@gmail.com> In-Reply-To: <594b7815-0611-34ea-beb5-0642114b5d82@gmail.com> From: Brendan Higgins Date: Mon, 27 Jan 2020 23:19:27 -0800 Message-ID: Subject: Re: [RFC v1 0/6] kunit: create a centralized executor to dispatch all KUnit tests To: Frank Rowand Cc: Luis Chamberlain , Jeff Dike , Richard Weinberger , Anton Ivanov , Arnd Bergmann , Kees Cook , Shuah Khan , Alan Maguire , Iurii Zaikin , David Gow , Andrew Morton , rppt@linux.ibm.com, Greg KH , Stephen Boyd , Logan Gunthorpe , Knut Omang , linux-um , linux-arch@vger.kernel.org, "open list:KERNEL SELFTEST FRAMEWORK" , KUnit Development , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 27, 2020 at 9:40 AM Frank Rowand wrote: > > On 1/23/20 4:40 PM, Brendan Higgins wrote: > > Sorry for the late reply. I am still catching up from being on vacation. > >> > On Mon, Jan 6, 2020 at 2:40 PM Luis Chamberlain wrote: > >> It does beg the question if this means kunit is happy to not be a tool > >> to test pre basic setup stuff (terminology used in init.c, meaning prior > >> to running all init levels). I suspect this is the case. > > > > Not sure. I still haven't seen any cases where this is necessary, so I > > am not super worried about it. Regardless, I don't think this patchset > > really changes anything in that regard, we are moving from late_init > > to after late_init, so it isn't that big of a change for most use > > cases. > > > > Please share if you can think of some things that need to be tested in > > early init. > > I don't have a specific need for this right now. I had not thought about > how the current kunit implementation forces all kunit tests to run at a > specific initcall level before reading this email thread. > > I can see the value of being able to have some tests run at different > initcall levels to verify what functionality is available and working > at different points in the boot sequence. Let's cross that bridge when we get there. It should be fairly easy to add that functionality. > But more important than early initcall levels, I do not want the > framework to prevent using or testing code and data that are marked > as '__init'. So it is important to retain a way to invoke the tests > while __init code and data are available, if there is also a change > to generally invoke the tests later. Definitely. For now that still works as long as you don't build KUnit as a module, but I think Alan's new patches which allow KUnit to be run at runtime via debugfs could cause some difficulty there. Again, we could add Kconfigs to control this, but the compiler nevertheless complains because it doesn't know what phase KUnit runs in. Is there any way to tell the compiler that it is okay for non __init code to call __init code? I would prefer not to have a duplicate version of all the KUnit libraries with all the symbols marked __init. Thoughts?