Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1070365ybb; Wed, 25 Mar 2020 15:12:25 -0700 (PDT) X-Google-Smtp-Source: ADFU+vt8EWEkM7er79R26MGY0gjnCYFt3XF+C/LcLuCB1Y6JxUh6twNHnO9hXgdhjoZWgYbVSNk8 X-Received: by 2002:a05:6830:1495:: with SMTP id s21mr4375154otq.35.1585174345152; Wed, 25 Mar 2020 15:12:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585174345; cv=none; d=google.com; s=arc-20160816; b=JQsOjdkkCVgfw1D9HAt3+1XXGZFUXxB/pj5YBLsHI3v8SfaHTfnjJamVbVMB1zg+Sd dZitrllKFiQwClLw8+ORsa8Wy8Y3zxDxBAebgpJmx3wyKOXuF+5af0kXRgo87j0otygP Xpu89tJoDhtTPMeLsBfwWk9abs+wXDCZKoJCirTGbQHdCFf/Yn3m9iJN4/JOxMo/k2cn o4Jb/MWCnobD7zW1uMv/bztLATV38R8xt3CtB+xua7a3l5UJqtWYZfoWaO2dqE5dP6wE XFshrqMIVwbDfg8Y4W6BeG3A8xSTmz4hTrc2IoHNRb2mgxaYuBgnOYhvjF+45pvr/NXj hqBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=dwZ+WrLFbzD/xrCzGrJHYZEAaeqlhCosTrKEPvy0Z/4=; b=gtt14mz+zusrKEbsfMF1CplJORFI5OUwVdjnIPtLWtwIt0xbRjEbvQQ/gyY64op8CB D24ZMY6SUruH0KGLo0+y8CevWpf5vJreRnzMDdj2aBHU1JL4SWqXT8HtIogPU5uG1fx3 NFGbDX0qxU1vgjHHIELwi0GZ3IUlzrzw6Hki5lw5UQvDTji5ooJSrc/Y/T9E1ZIXg4Hp N2LBqOliPUBPsa8gdjMFlYkgVbknc8G5/sYkzz1uzqtOu+qKTusJ5SLPtrBQFjEGQcCk OHB960z0AAE3+Q/ZdrEXobps9+0NTa6W6jRgbPzki7bETFtoYMZf77XcMKepNtzw+9cc 5DBw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=civQwJIX; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c1si185710oto.260.2020.03.25.15.12.13; Wed, 25 Mar 2020 15:12:25 -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=@kernel.org header.s=default header.b=civQwJIX; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727537AbgCYWLL (ORCPT + 99 others); Wed, 25 Mar 2020 18:11:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:48904 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727358AbgCYWLL (ORCPT ); Wed, 25 Mar 2020 18:11:11 -0400 Received: from [192.168.1.112] (c-24-9-64-241.hsd1.co.comcast.net [24.9.64.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AC2D520719; Wed, 25 Mar 2020 22:11:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585174270; bh=yWNg9yztHt+7I4h0soifkK3UL3DvWslZVJ7YKdYxXzM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=civQwJIX1MzK96vfW26z8Mc4qQdpo12r5aMh1NIM9mjYIm7Nr8ig9pskeVZ2uGAF9 9VNljHBmxcbjtmyVADgCM4D189mssdgH2VezZbOGKaiQvMRNpudaIzmCLLKVwe+ZyR uiv8YskcJTZHhmHcZLso+ITce7hQ4QCHPzOXg0Dw= Subject: Re: [PATCH v7 kunit-next 3/4] kunit: subtests should be indented 4 spaces according to TAP To: Alan Maguire Cc: brendanhiggins@google.com, frowand.list@gmail.com, gregkh@linuxfoundation.org, corbet@lwn.net, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, kunit-dev@googlegroups.com, linux-doc@vger.kernel.org, shuah References: <1584110682-3837-1-git-send-email-alan.maguire@oracle.com> <1584110682-3837-4-git-send-email-alan.maguire@oracle.com> From: shuah Message-ID: <6b41e9fe-aa9e-698b-d356-0227e6f2021c@kernel.org> Date: Wed, 25 Mar 2020 16:11:08 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/25/20 4:03 PM, Alan Maguire wrote: > On Wed, 25 Mar 2020, shuah wrote: > >> On 3/13/20 8:44 AM, Alan Maguire wrote: >>> Introduce KUNIT_INDENT macro which corresponds to 4-space indentation, >>> and use it to modify indentation from tab to 4 spaces. >>> >>> Suggested-by: Frank Rowand >>> Signed-off-by: Alan Maguire >>> Reviewed-by: Frank Rowand >>> --- >>> include/kunit/test.h | 7 +++- >>> lib/kunit/assert.c | 79 >>> +++++++++++++++++++------------------ >>> lib/kunit/test.c | 6 +-- >>> tools/testing/kunit/kunit_parser.py | 10 ++--- >>> 4 files changed, 54 insertions(+), 48 deletions(-) >>> >>> diff --git a/include/kunit/test.h b/include/kunit/test.h >>> index f7b2ed4c..d49cdb4 100644 >>> --- a/include/kunit/test.h >>> +++ b/include/kunit/test.h >>> @@ -84,6 +84,10 @@ struct kunit_resource { >>> /* Size of log associated with test. */ >>> #define KUNIT_LOG_SIZE 512 >>> >>> +/* TAP specifies subtest indentation of 4 spaces. */ >>> +#define KUNIT_INDENT " " >>> +#define KUNIT_INDENT2 KUNIT_INDENT KUNIT_INDENT >> >> Sorry for a late comment on this. >> >> What's the reason to do it this way? Why wouldn't you define >> it as 8 spaces long string? >> > > I could have I suppose; I thought it makes it a bit easier > to read as above (though it did generate a checkpatch > warning; I thought readability was more important in this > case, but I can alter if needed). > Please do. Couple of things. KUNIT_INDENT2 doesn't really tell me much. Same with KUNIT_INDENT Please make the names more descriptive. Something along the lines of KUNIT_INDENT_4SPACE KUNIT_INDENT_8SPACE >> Also can you please make sure to run checkpatch --strict on the >> patches you send? >> > > Sure! There were also some other line-too-long warnings > generated as a result of this patch, but when I fixed those > checkpatch complained about splitting strings across multiple > lines. The only way out was to reduce the amount of information > in the log messages, which I didn't want to do. In future I can > note checkpatch warnings that I couldn't find a way to fix in the > commit message if that would help? > I understand. This is an error though. I am willing to ignore line-too long warnings for the most part. I don't like to see errors in general. thanks, -- Shuah