Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp7803391yba; Thu, 2 May 2019 17:00:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqxA+dySU83NPBLhN5JfyidcZXnaRPKArVn54YAYyrF6dVcYdMDmkfqpR0pFzL44/k6GNVvj X-Received: by 2002:a63:f012:: with SMTP id k18mr6982218pgh.433.1556841632917; Thu, 02 May 2019 17:00:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556841632; cv=none; d=google.com; s=arc-20160816; b=Wx3OYW9mNRfPsDMwVDS6ZuxKGqjt2BXagx4kvPMD17TBxAuG345ccD0m0nuTK8xCL7 KwKlOAImfQWqmBqkGk0GhRmRfRapGvBkiW0AA2YqnRtozdy1mrAXjg+IwghT3Knx3qiu zK0+D7ZKqk9nHmLdEw7pOpppnJVfjlCk6P7nX2IsBU+rEiSqVPs2SSJTEV9voCkEQK8S ETOvQVKV/rGlr1nmmaHJ+G5dZT/1R5oC8XakFwQfZa38XvC1/wbY6+J8zafvKIXz3c0w b0xpG9DWzrzZ4UzyUY93WcRPsQPwwqq6avEzlZiew/euNuElK5YvquG1TYZmAcTLBvev LizA== 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=ylV5gAlOXI2nFNZnhMPfqqvANEP1/evAl3taiRkcInQ=; b=vVuce21FTe8PSyfwofY3UPb+hMHMgT0wKAG34cDSCxkXSDmGS3uu8IG3P20Ul7H/d5 LGzG4u0oJ0A+o1RS2I26F0hqlH7aLm6Sv0lTuH+fVs2KH07uul0tIDU1+85y/5PxyMas TfHeM0FKzimOQOtLuqOfhGVCV8ijNXEOqexeqkmrYkZULyFo7fgzWn9bvHRT2AiqC5yT Ul5pYntrkso9osPZchlKIpd/UnJtt1ezzCvf3E6ORhQKoBY1zNF/DpdXJuag2dZjsivP PY1AQoo1jNjrgDYLlCb1hSieFcEMBKVPX3LGhDxytgxLZW5FDL74/aRKiriYWXP7Ey0m 6+Sw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=OrjlPAyp; 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 13si433020pfi.270.2019.05.02.17.00.13; Thu, 02 May 2019 17:00:32 -0700 (PDT) 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=OrjlPAyp; 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 S1726350AbfEBXpm (ORCPT + 99 others); Thu, 2 May 2019 19:45:42 -0400 Received: from mail-oi1-f194.google.com ([209.85.167.194]:40846 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726053AbfEBXpm (ORCPT ); Thu, 2 May 2019 19:45:42 -0400 Received: by mail-oi1-f194.google.com with SMTP id y64so3150938oia.7 for ; Thu, 02 May 2019 16:45:41 -0700 (PDT) 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=ylV5gAlOXI2nFNZnhMPfqqvANEP1/evAl3taiRkcInQ=; b=OrjlPAypoDuLTmMWabsyH76U4J0Mgjkpr3DQnHBX1C/sWw9dQWGJZqdGNPLs+jVmSg c3bYyd65ExNrwdSzAF9/C3j2TwsTXUxo6mYRYKux2ifXavoN2kS9n00OiZWShZJ2VN9E Jey0nYLCGUng4+ySvL4+XGzNZ7sYP4XCUNcymRLj9xf6jLOnFx+3mvowrkn0pYKwRyZg 3M2fA5czV+OipZELphNhEy5iD2t61ukDrrNzVoHA9OjKJNH0VGnLzAHCbuiCf9QjtvzN IDmzum+SPe0jeiAShs/g76LnFAxiI2OcVPBTp+1OnYkCXtTKkvmMFQSC+CcJJLS2aj7L YRtg== 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=ylV5gAlOXI2nFNZnhMPfqqvANEP1/evAl3taiRkcInQ=; b=efJ5VewyMzKxgm5/PDCWk7t0PONyYilKuZZi34kJ6o7sDTix30VB14OUBpkV4lLrsf 5KVbXg6TtRDiife++j9XKaqSxxQawd5XzRyHgS2uNTGxt8PoeOBWVXnJcxaReVQzYYP3 kPOuQ+a3j4Cr1/xh//bRhDeYvTMbIibSzKjDr7GGDGUmEfGppUussppJ5g4/kG/lSDP+ CYOZ375t04Zw/PLQCze2bwQeb/D0K5L5FCJyEjCRkxB3TtnsX3gJww1IdHPWmKFTGOnG pZ04ZuI8IBnVxrrUJOVeaP4rv699nJYwAMoS+evpHc2bC2xBCvnl0drN2w6qVq8EqJ0F y1xw== X-Gm-Message-State: APjAAAVpLqRpoTa4QrDAGBWmBEyTwhoST6LuWNcNwz6WlTa5CCvJvUOg pemwux3VtER+5iz7RQmiIxctkbRU6VjebXVvX4RZMw== X-Received: by 2002:aca:57d8:: with SMTP id l207mr4208582oib.44.1556840740661; Thu, 02 May 2019 16:45:40 -0700 (PDT) MIME-Version: 1.0 References: <20190501230126.229218-1-brendanhiggins@google.com> <20190501230126.229218-13-brendanhiggins@google.com> <20190502110220.GD12416@kroah.com> In-Reply-To: From: Brendan Higgins Date: Thu, 2 May 2019 16:45:29 -0700 Message-ID: Subject: Re: [PATCH v2 12/17] kunit: tool: add Python wrappers for running KUnit tests To: Frank Rowand Cc: Greg KH , Kees Cook , Kieran Bingham , Luis Chamberlain , Rob Herring , Stephen Boyd , shuah@kernel.org, devicetree , dri-devel , kunit-dev@googlegroups.com, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kbuild@vger.kernel.org, Linux Kernel Mailing List , linux-kselftest@vger.kernel.org, linux-nvdimm , linux-um@lists.infradead.org, Sasha Levin , "Bird, Timothy" , Amir Goldstein , Dan Carpenter , Dan Williams , Daniel Vetter , Jeff Dike , Joel Stanley , Julia Lawall , Kevin Hilman , Knut Omang , Logan Gunthorpe , Michael Ellerman , Petr Mladek , Richard Weinberger , David Rientjes , Steven Rostedt , wfg@linux.intel.com, Felix Guo 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 Thu, May 2, 2019 at 2:16 PM Frank Rowand wrote: > > On 5/2/19 11:07 AM, Brendan Higgins wrote: > > On Thu, May 2, 2019 at 4:02 AM Greg KH wrote: > >> > >> On Wed, May 01, 2019 at 04:01:21PM -0700, Brendan Higgins wrote: > >>> From: Felix Guo > >>> > >>> The ultimate goal is to create minimal isolated test binaries; in the > >>> meantime we are using UML to provide the infrastructure to run tests, so > >>> define an abstract way to configure and run tests that allow us to > >>> change the context in which tests are built without affecting the user. > >>> This also makes pretty and dynamic error reporting, and a lot of other > >>> nice features easier. > >>> > >>> kunit_config.py: > >>> - parse .config and Kconfig files. > >>> > >>> kunit_kernel.py: provides helper functions to: > >>> - configure the kernel using kunitconfig. > >>> - build the kernel with the appropriate configuration. > >>> - provide function to invoke the kernel and stream the output back. > >>> > >>> Signed-off-by: Felix Guo > >>> Signed-off-by: Brendan Higgins > >> > >> Ah, here's probably my answer to my previous logging format question, > >> right? What's the chance that these wrappers output stuff in a standard > >> format that test-framework-tools can already parse? :) To be clear, the test-framework-tools format we are talking about is TAP13[1], correct? My understanding is that is what kselftest is being converted to use. > > > > It should be pretty easy to do. I had some patches that pack up the > > results into a serialized format for a presubmit service; it should be > > pretty straightforward to take the same logic and just change the > > output format. > > When examining and trying out the previous versions of the patch I found > the wrappers useful to provide information about how to control and use > the tests, but I had no interest in using the scripts as they do not > fit in with my personal environment and workflow. > > In the previous versions of the patch, these helper scripts are optional, > which is good for my use case. If the helper scripts are required to They are still optional. > get the data into the proper format then the scripts are not quite so > optional, they become the expected environment. I think the proper > format should exist without the helper scripts. That's a good point. A couple things, First off, supporting TAP13, either in the kernel or the wrapper script is not hard, but I don't think that is the real issue that you raise. If your only concern is that you will always be able to have human readable KUnit results printed to the kernel log, that is a guarantee I feel comfortable making. Beyond that, I think it is going to take a long while before I would feel comfortable guaranteeing anything about how will KUnit work, what kind of data it will want to expose, and how it will be organized. I think the wrapper script provides a nice facade that I can maintain, can mediate between the implementation details and the user, and can mediate between the implementation details and other pieces of software that might want to consume results. [1] https://testanything.org/tap-version-13-specification.html