Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp1034630rwl; Wed, 29 Mar 2023 11:38:16 -0700 (PDT) X-Google-Smtp-Source: AKy350ZXzMJms5Yh1hOc6uFENkMHWF8H8axdBu7LWM2tyMiT9MM0Fqf9v4f4V/rLPb0NmIf4vwJF X-Received: by 2002:a17:903:1053:b0:1a1:cc91:c44f with SMTP id f19-20020a170903105300b001a1cc91c44fmr15515886plc.1.1680115096115; Wed, 29 Mar 2023 11:38:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680115096; cv=none; d=google.com; s=arc-20160816; b=QPPc0aPvnPumzC3XJLvLN6E4SbiL/P7/AwDY0BamCyjGfUSEBqgDOd05hQbAlJixM4 l3iMh7Vu28XcOIjwDy31K6XFmUD+Rj1rdotw4nMmXXxtLYpDPOPFRer/0Hpw6xu9Wm8U 5HoPyRTvWSipj1NeZ2uYH/aBMNtf4teezSw8a0WM0vxfMI6O1GxeoCSJlJ9MOpGai0dk 7/lEWLB4RTHJtRh7+DNHOD5pCcGP9z4y7CaxGTYCYzQ6s0EMN9TJpxNbL77BxKY05U+S BmgaKhdvkuD3bKPVE8zzZ8Up4ji97kxArJrwCcbvFj82nYWB3qnmx16hhhP096Thg0So OI4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=uoayQot9L/nb+F2GoEpkM/VcmhepGMqPcvXnqxbtncM=; b=wYWtzmzXGl+3SqemmbaSRfbx2HoJRt/Lk4stVMvnThj2xJdCos7ymEFUzoYDEDJi5/ igvH2UTaChgNyjyPmjin6+6Sog6xP5Ui7bEoQ+pm0Vmc2g8DGimrt7mB16YRjUvn9rUm a+JOl/QwqPO+sXzhZJ68tlk/Tp8i+4xvAs2BWOQsAQeEylEmdk2OGp732Uo+cAWj3zyM okNYlIJjjeoq5EIbpcTcrlS6PVN5t+XiHBxg9YYzIDDROXorF2y8jBerumXeJOFmSiZ+ 3quAJpRFr1k8gALWFCTaKDIDQE/vD8yInyt6Hmjn4+siemcFkrdYq+kpm2AQRJjpcLw9 FBWw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=a69vJ2oq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a3-20020a170902ecc300b001a1e782c0c4si20275988plh.286.2023.03.29.11.38.03; Wed, 29 Mar 2023 11:38:16 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=a69vJ2oq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S229610AbjC2SfG (ORCPT + 99 others); Wed, 29 Mar 2023 14:35:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36190 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229504AbjC2SfF (ORCPT ); Wed, 29 Mar 2023 14:35:05 -0400 Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C2C752D55 for ; Wed, 29 Mar 2023 11:35:01 -0700 (PDT) Received: by mail-yb1-xb2d.google.com with SMTP id b18so20588748ybp.1 for ; Wed, 29 Mar 2023 11:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680114901; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=uoayQot9L/nb+F2GoEpkM/VcmhepGMqPcvXnqxbtncM=; b=a69vJ2oq4PwoxM9o2LP+M7Jp7bme3nYOwqjVWq91UXNrsdXXmwnticS6w+W049jGeu 7ECoWiVHKD9STJG948OdsXLaOBa339f4u4J4WoQnmZQdr5q7GnpDV2SL6o6pa/RiTYpF 5K8ZVbJra9Xc5fTqYY3Qc2Dxv72LuZZxMVvpD6yRlLjfQ2ssI6co232RDrdgPwqGQGww zm9/pU5YWYbmHdLJ47rAOOBwx4CzQXWb1glKTqVX4BMKto+fhG8zCSTOjM2aa/cuUAAQ VjNVUMyty0JUbKdDTUYYpbBVMECT7QDfbWCIGnLtrv21wrDiEgSn0Wl3kNB3YuO7qpAC f0Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680114901; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uoayQot9L/nb+F2GoEpkM/VcmhepGMqPcvXnqxbtncM=; b=cwTlBYjcgOhWBgw7YY4c1YHLfj1s5mupcMx3/Z/UGdOjEBue1+FmY7ViZsnJSAcWDH sCvB79tqRDznVTEATCkPDmSgS12Z8YabYC9fnEYhBg42WAKOyHBgcKhWJ7ifIJBddOq8 0f9BcJUKD++OJyGRQY86Tmx0kQ2W37wD0F07AV5yHUFkOHhGiumGexVN90NyMqCrEz6W gJ+2TGE/DxlYM4dakQTMO4qihI8CZU8V7pGBeDQuSf7dAOjhcDk0gldEuJxej3S5d8AO e4zh9Y4QbQabobElnMLtB+mc7LKTPhLzvamJo9QMcAVs9DrIVlffUJ6t2pOazjbDrcdw QzIQ== X-Gm-Message-State: AAQBX9f0C0M4h/vNT2OIQh8ILnJ7/ayRyBBSAcTWWOst5ai17dbCoV+8 gETLwfSYrlhQ9Fs+W6gUp9BldMdJSqcNmAnhdWANoQ== X-Received: by 2002:a05:6902:1247:b0:b78:4b00:7772 with SMTP id t7-20020a056902124700b00b784b007772mr12183690ybu.5.1680114900775; Wed, 29 Mar 2023 11:35:00 -0700 (PDT) MIME-Version: 1.0 References: <20230316225915.494688-1-rmoar@google.com> <197889b6-5773-094c-8699-26843c6519fd@gmail.com> In-Reply-To: <197889b6-5773-094c-8699-26843c6519fd@gmail.com> From: Rae Moar Date: Wed, 29 Mar 2023 14:34:49 -0400 Message-ID: Subject: Re: [KTAP V2 PATCH] ktap_v2: add recognized test name line To: Frank Rowand Cc: davidgow@google.com, skhan@linuxfoundation.org, keescook@chromium.org, Tim.Bird@sony.com, brendanhiggins@google.com, corbet@lwn.net, guillaume.tucker@collabora.com, dlatypov@google.com, kernelci@lists.linux.dev, kunit-dev@googlegroups.com, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-15.7 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=unavailable 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: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 26, 2023 at 10:41=E2=80=AFPM Frank Rowand wrote: > > On 3/16/23 17:59, Rae Moar wrote: > > Add recognition of the test name line ("# Subtest: ") to the KTAP= v2 > > spec. > > > > The purpose of this line is to declare the name of a test before its > > results. This functionality is especially useful when trying to parse t= est > > results incrementally and when interpretting results after a crash. > > > > This line is already compliant with KTAP v1 as it is interpretted as a > > diagnostic line by parsers. Additionally, the line is currently used by > > KUnit tests and was derived from the TAP 14 spec: > > https://testanything.org/tap-version-14-specification.html. > > It is convenient that "# Subtest: " is compatible with v1, but I th= ink > that there is a negative that overrides the convenience. > > The "# Subtest: " syntax means that we need to restrict the format = of > diagnostic lines, such that "#Subtest:" is an illegal diagnostic, at leas= t > for the line immediately following the Version line. > Hi Frank, Yes, I see what you are saying here. It would be inconvenient for parsers to make an exception to the method of parsing diagnostic lines. > I think it would be cleaner to modify the Version line syntax to be: > > KTAP version 2 [# ] > I like that this idea wouldn't introduce a new line, which is invaluable. However, I would suspect this alternative may break more parsers than the first proposal, as current parsers may search for the full version line to find KTAP results (I know at least KUnit does this). Therefore I slightly prefer the original proposal. Curious what others prefer? Overall, I advocate that KTAP should allow a way to define the name of the test prior to the results based on the reasons discussed above and by Daniel and Frank. So if this is the preferred method I would understand. > I notice that the KTAP Specification version 1 fails to specify the > Version line syntax. So the Specification would be updated from: > > All KTAP-formatted results begin with a "version line" which specifies = which > version of the (K)TAP standard the result is compliant with. > > For example: > - "KTAP version 1" > - "TAP version 13" > - "TAP version 14" > > to: > > The Version line is required and must have the format: > > .. code-block:: none > > KTAP version 2 [# ] > I like this added specificity. Would be happy to see specific version line syntax added to the spec. Thanks! Rae > All KTAP-formatted results begin with a "version line" which specifies = which > version of the (K)TAP standard the result is compliant with. > > For example: > - "KTAP version 2" > - "TAP version 13" > - "TAP version 14" > > > > > Recognition of this line would create an accepted way for different tes= t > > frameworks to declare the name of a test before its results. > > > > The proposed location for this line is between the version line and the > > test plan line. This location ensures that the line would not be > > accidentally parsed as a subtest's diagnostic lines. Note this proposed > > location would be a slight differentiation from KTAP v1. > > > > Example of test name line: > > > > KTAP version 2 > > # Subtest: main_test > > 1..1 > > KTAP version 2 > > # Subtest: sub_test > > 1..2 > > ok 1 test_1 > > ok 2 test_2 > > ok 1 sub_test > > > > Here is a link to a version of the KUnit parser that is able to parse t= he > > test name line for KTAP version 2. Note this includes a test name line = for > > the main level of KTAP. > > > > Link: https://kunit-review.googlesource.com/c/linux/+/5709 > > > > Signed-off-by: Rae Moar > > --- > > > > This is a RFC. I would like to know what people think and use this as a > > platform for discussion on KTAP v2. > > > > Note: this patch is based on Frank's ktap_spec_version_2 branch. > > > > Documentation/dev-tools/ktap.rst | 19 ++++++++++++++----- > > 1 file changed, 14 insertions(+), 5 deletions(-) > > > > diff --git a/Documentation/dev-tools/ktap.rst b/Documentation/dev-tools= /ktap.rst > > index ff77f4aaa6ef..9c7ed66d9f77 100644 > > --- a/Documentation/dev-tools/ktap.rst > > +++ b/Documentation/dev-tools/ktap.rst > > @@ -28,8 +28,7 @@ KTAP output is built from four different types of lin= es: > > In general, valid KTAP output should also form valid TAP output, but s= ome > > information, in particular nested test results, may be lost. Also note= that > > there is a stagnant draft specification for TAP14, KTAP diverges from = this in > > -a couple of places (notably the "Subtest" header), which are described= where > > -relevant later in this document. > > +a couple of places, which are described where relevant later in this d= ocument. > > > > Version lines > > ------------- > > @@ -44,8 +43,8 @@ For example: > > - "TAP version 14" > > > > Note that, in KTAP, subtests also begin with a version line, which den= otes the > > > -start of the nested test results. This differs from TAP14, which uses = a > > -separate "Subtest" line. > > ^^^^ This is an error in the KTAP Specification version 1. TAP14 allows = the case > of "Bare Subtests", which would be the equivalent of the KTAP v1 method. > > > +start of the nested test results. This differs from TAP14, which uses = only a > > +"Subtest" line. > > > > While, going forward, "KTAP version 2" should be used by compliant tes= ts, it > > is expected that most parsers and other tooling will accept the other = versions > > @@ -166,6 +165,12 @@ even if they do not start with a "#": this is to c= apture any other useful > > kernel output which may help debug the test. It is nevertheless recomm= ended > > that tests always prefix any diagnostic output they have with a "#" ch= aracter. > > > > +One recognized diagnostic line is the "# Subtest: " line. This l= ine > > +is used to declare the name of a test before subtest results are print= ed. This > > +is helpful for parsing and for providing context during crashes. As a = rule, > > +this line is placed after the version line and before the plan line. N= ote > > +this line can be used for the main test, as well as subtests. > > + > > Unknown lines > > ------------- > > > > @@ -206,6 +211,7 @@ An example of a test with two nested subtests: > > KTAP version 2 > > 1..1 > > KTAP version 2 > > + # Subtest: example > > 1..2 > > ok 1 test_1 > > not ok 2 test_2 > > @@ -219,6 +225,7 @@ An example format with multiple levels of nested te= sting: > > KTAP version 2 > > 1..2 > > KTAP version 2 > > + # Subtest: example_test_1 > > 1..2 > > KTAP version 2 > > 1..2 > > @@ -245,7 +252,7 @@ allows an arbitrary number of tests to be nested = no yes > > > > The TAP14 specification does permit nested tests, but instead of using= another > > nested version line, uses a line of the form > > -"Subtest: " where is the name of the parent test. > > +"Subtest: " where is the name of the parent test as discu= ssed above. > > > > Example KTAP output > > -------------------- > > @@ -254,6 +261,7 @@ Example KTAP output > > KTAP version 2 > > 1..1 > > KTAP version 2 > > + # Subtest: main_test > > 1..3 > > KTAP version 2 > > 1..1 > > @@ -266,6 +274,7 @@ Example KTAP output > > ok 2 test_2 > > ok 2 example_test_2 > > KTAP version 2 > > + # Subtest: example_test_3 > > 1..3 > > ok 1 test_1 > > # test_2: FAIL > > > > base-commit: 906f02e42adfbd5ae70d328ee71656ecb602aaf5 > > -- > You received this message because you are subscribed to the Google Groups= "KUnit Development" group. > To unsubscribe from this group and stop receiving emails from it, send an= email to kunit-dev+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgi= d/kunit-dev/197889b6-5773-094c-8699-26843c6519fd%40gmail.com.