Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1139078yba; Fri, 3 May 2019 17:11:10 -0700 (PDT) X-Google-Smtp-Source: APXvYqzFF54/pT4usp1hmjvohke+OUHl7jV/lQ6nZSv/v90Q68nSjUwHK1lbss78v4sTtIZpDRMS X-Received: by 2002:a17:902:e512:: with SMTP id ck18mr14014845plb.251.1556928670610; Fri, 03 May 2019 17:11:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556928670; cv=none; d=google.com; s=arc-20160816; b=FVP9s/hhrxDuz3nAJL0aJc9G+L09AxxVAGPKTU5qbEMpcTvBPs2Ip+tyCJWeSxgRFw SFWtV+bJzJMi6i8GCf/TJyDjgtCNlNpVVwHFWCnFh2X48K865i+BZD7KkJGqKdVoAQHT 6LNxP7GBfLFxiG4sAl3EvlcRCRtUQ1Uw2WOVkUNEdpQnf46El11cUrGHPNSomulgiVkA KXBa8kcWPWttERPGxkUm8nepprTHWylbsR1L+faZ6s4S6B3egra020XJ03hFxV6PNWoE PEufixxDJOnR9dqBAoaI7qf0F+ZEL9xEIJZE6mWrj9IslrLAK6RnVxsQ2PucFqn/M0Ho r53A== 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=mKALN1OkcwtQhcysb+FWH3t2vFKNjrdMKVQt2ijO0Po=; b=Zjm4KBCzRURVbmNKhTy4YRQFHb5kyLuEXrzmL+DGwM9Y5HVP2aJMOQ6Xvb7Gc1vSmr t9pIiutoIkagWtzWfX1RR4JsYnWfqRMGlJTcc9MtVtRJJGdeNcuW9j2KwZoYTgmqF7Dy dkA9isjRJtkK1CStBdIweKZYhzPrW3tjRYsFLyxTwPnUGcAXrZZqHS6boLmgBvVB0tkK I2sFSAvsCFXnQIT7SmxdU7fmzqXOxkXiLWcGCaCEJvu+Pxm8JhBgySzyXDr+CsM78K4j d1aa1Q4YXx6EQOMkEbCT1wbJtfulh31MBky/4H0PAKNF0DdvBGZXuHmTG5FpKtgv9PQL f5Vg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=uHwVMflH; 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 u22si4502685plq.193.2019.05.03.17.10.54; Fri, 03 May 2019 17:11:10 -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=uHwVMflH; 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 S1726769AbfECXlY (ORCPT + 99 others); Fri, 3 May 2019 19:41:24 -0400 Received: from mail-ot1-f68.google.com ([209.85.210.68]:37240 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726326AbfECXlX (ORCPT ); Fri, 3 May 2019 19:41:23 -0400 Received: by mail-ot1-f68.google.com with SMTP id u3so1346751otq.4 for ; Fri, 03 May 2019 16:41:22 -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=mKALN1OkcwtQhcysb+FWH3t2vFKNjrdMKVQt2ijO0Po=; b=uHwVMflHMaQY3whJ1EE4nVizGRxOy/tr5WOjeZAzMUNneEi1VOxLR7ILboGXaDspKX EZdcTnWDLsjH5Xuv6Dpbla+mLd+ZOej6UTDsdicbg1f2NGRfNWvT53QLlViJ91MtO47Y +NMNZSv0/KOCCjGp/8Z6JcV8oAgctk1uHe5BjikYU+meECnNZzF0Xtb+m6Lql1RyQZ+f 6pOCAlUul4FDKtOsuwcFiCf6Z4SU4Q97jpl1Ljx2pJqKs6Ok7cLSU5UcjCBf989disYo L1k/caWEqmSpv8hm8mIrQVDY6SOrZ43BcimXmBjT67ScyO4HOEunsbiGdbsaE+Lu0zj7 pGEA== 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=mKALN1OkcwtQhcysb+FWH3t2vFKNjrdMKVQt2ijO0Po=; b=pocKFCruwqx8rC5oxXcppsKowiAjEOA5Qj5igE6ycP06lp3Z7ZzlbES8LrITRXS+wG HJR+9v5b6l5qpIBMcwYHNzXViJoGQEh/K2HoJrZ4PmFwWJIpb8pOLB0lMffWwWEnh+z1 NL8ut9c0f217epnXEHBEUxabFlldLVbpaKn9UyfTbRHfmT6EvY5RPkoJeYkrEz+JAEau +blkAKHwWrM9v0xKMH/o3+VIKUd77IQC4lBsXxglun1Wq9ddscQmSPhMcUZICUQU/pwh pLGV2GwmmLHxSYofGSjlOWEld29+AeSJBpfmw2tMD3Rw1nV0IxMhGjdZ2nDt+vjH0nVV BhtA== X-Gm-Message-State: APjAAAW7UVkXwzW8sN+Le88fOxWlgJnP1qoIdoXwKk9KxSTPwBx3jEsu qNFnQnAmR2H3f8xzADXESKorMG/h9JAMUHVc3lN6/w== X-Received: by 2002:a9d:5cc3:: with SMTP id r3mr8335667oti.338.1556926881968; Fri, 03 May 2019 16:41:21 -0700 (PDT) MIME-Version: 1.0 References: <20190501230126.229218-1-brendanhiggins@google.com> <20190501230126.229218-17-brendanhiggins@google.com> <20190502110347.GE12416@kroah.com> <20190503064241.GC20723@kroah.com> In-Reply-To: <20190503064241.GC20723@kroah.com> From: Brendan Higgins Date: Fri, 3 May 2019 16:41:10 -0700 Message-ID: Subject: Re: [PATCH v2 16/17] kernel/sysctl-test: Add null pointer test for sysctl.c:proc_dointvec() To: Greg KH Cc: "Bird, Timothy" , Frank Rowand , Kees Cook , Kieran Bingham , Luis Chamberlain , Rob Herring , Stephen Boyd , shuah , 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 , 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, Iurii Zaikin 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 02, 2019 at 11:45:43AM -0700, Brendan Higgins wrote: > > On Thu, May 2, 2019 at 11:15 AM wrote: > > > > > > > > > > > > > -----Original Message----- > > > > From: Greg KH > > > > > > > > On Wed, May 01, 2019 at 04:01:25PM -0700, Brendan Higgins wrote: > > > > > From: Iurii Zaikin > > > > > > > > > > KUnit tests for initialized data behavior of proc_dointvec that is > > > > > explicitly checked in the code. Includes basic parsing tests including > > > > > int min/max overflow. > > > > > > > > > > Signed-off-by: Iurii Zaikin > > > > > Signed-off-by: Brendan Higgins > > > > > --- > > > > > kernel/Makefile | 2 + > > > > > kernel/sysctl-test.c | 292 > > > > +++++++++++++++++++++++++++++++++++++++++++ > > > > > lib/Kconfig.debug | 6 + > > > > > 3 files changed, 300 insertions(+) > > > > > create mode 100644 kernel/sysctl-test.c > > > > > > > > > > diff --git a/kernel/Makefile b/kernel/Makefile > > > > > index 6c57e78817dad..c81a8976b6a4b 100644 > > > > > --- a/kernel/Makefile > > > > > +++ b/kernel/Makefile > > > > > @@ -112,6 +112,8 @@ obj-$(CONFIG_HAS_IOMEM) += iomem.o > > > > > obj-$(CONFIG_ZONE_DEVICE) += memremap.o > > > > > obj-$(CONFIG_RSEQ) += rseq.o > > > > > > > > > > +obj-$(CONFIG_SYSCTL_KUNIT_TEST) += sysctl-test.o > > > > > > > > You are going to have to have a "standard" naming scheme for test > > > > modules, are you going to recommend "foo-test" over "test-foo"? If so, > > > > that's fine, we should just be consistant and document it somewhere. > > > > > > > > Personally, I'd prefer "test-foo", but that's just me, naming is hard... > > > > > > My preference would be "test-foo" as well. Just my 2 cents. > > > > I definitely agree we should be consistent. My personal bias > > (unsurprisingly) is "foo-test," but this is just because that is the > > convention I am used to in other projects I have worked on. > > > > On an unbiased note, we are currently almost evenly split between the > > two conventions with *slight* preference for "foo-test": I ran the two > > following grep commands on v5.1-rc7: > > > > grep -Hrn --exclude-dir="build" -e "config [a-zA-Z_0-9]\+_TEST$" | wc -l > > grep -Hrn --exclude-dir="build" -e "config TEST_[a-zA-Z_0-9]\+" | wc -l > > > > "foo-test" has 36 occurrences. > > "test-foo" has 33 occurrences. > > > > The things I am more concerned about is how this would affect file > > naming. If we have a unit test for foo.c, I think foo_test.c is more > > consistent with our namespacing conventions. The other thing, is if we > > already have a Kconfig symbol called FOO_TEST (or TEST_FOO) what > > should we name the KUnit test in this case? FOO_UNIT_TEST? > > FOO_KUNIT_TEST, like I did above? > > Ok, I can live with "foo-test", as you are right, in a directory listing > and config option, it makes more sense to add it as a suffix. Cool, so just for future reference, if we already have a Kconfig symbol called FOO_TEST (or TEST_FOO) what should we name the KUnit test in this case? FOO_UNIT_TEST? FOO_KUNIT_TEST, like I did above?