Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp1885222ybe; Thu, 12 Sep 2019 00:45:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqxVBPbxBA0VO5mYGbMpgzh1E3fGvaDdTcizVtYGJVySujjs38uzHxtnNlgyoNOH+vrrRsV5 X-Received: by 2002:a17:906:134e:: with SMTP id x14mr33304268ejb.280.1568274326747; Thu, 12 Sep 2019 00:45:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568274326; cv=none; d=google.com; s=arc-20160816; b=SPmKFmFuVJjTeIbkp4OqpPSGZwQNHsR8CQfplwA/6DgxeOVbSRAgYmzzBFF1ekkgNV gZVWVZdkjdOnQqQXEoZaoINo5xG5IfK6bQDd9kk43H/edh7IjM/lb55108EATATUF7rR PVlGM6Mhn/3O1Psqa/vB4vJKXAjzmKNhTpHwtB0kKuh544F71bQs8acXNTmz6v2Gme51 /MNTEnTXEhUtTgouk7DuT6v5Gkk7rBIV8BJ93MerLkqBzkQewNx2kuRv8B9sbvPSEhwf RtFiX5FeS/xXGX7qWtG7GzTxjYlBru8lfJOnr9sJ/gUJM4RxyjLIP8rntUY/P1K+mJwD u+OQ== 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=o8LTeC4govd1fNBJO0ioJqcSmCWQfNIKLUUZIaiAhHg=; b=kUn7P1rDQK4iS+z8EH+eGOjEc0AGeIApruawvJJgeFUNo6AjY/IZfz8GjqNxpBvW8M y3fYH99fxJ9MATj3twYEeMKotNJm3D/6N/EBHQ3DmHxNZ7k2C2gIXS/5lCbIjEWWoA+l VYU765+goF+WJLK68JEbAVdDlw5BaEMHpJcqT0OYi5kWtMRYwwPMgs201CGC2k6RO0ki txMzj8FHWheHlFdk4Obt9MivoWko2HrznlW/BUBhHK8ES4Cin2IkvLh0CDXuGPULhVWm k/GNBWDp0JbxYztZtncKv1dlZGXewtjQk6N036lgz5f1OVLeTVnd9j3k8vpaQNL+6sf6 8ThA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=r5iciw4g; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l25si12390516ejr.311.2019.09.12.00.45.03; Thu, 12 Sep 2019 00:45:26 -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=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=r5iciw4g; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729781AbfILHlh (ORCPT + 99 others); Thu, 12 Sep 2019 03:41:37 -0400 Received: from mail-oi1-f194.google.com ([209.85.167.194]:34831 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729391AbfILHlh (ORCPT ); Thu, 12 Sep 2019 03:41:37 -0400 Received: by mail-oi1-f194.google.com with SMTP id a127so16378757oii.2 for ; Thu, 12 Sep 2019 00:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o8LTeC4govd1fNBJO0ioJqcSmCWQfNIKLUUZIaiAhHg=; b=r5iciw4g8aqTCdevxlX7Yl1qKRDD/phXv4v2oTTELHQGit1wxhO/OmSHjpMCzaPPrC Vr8pfrqAPKZP/QRditALJa3T7m3utIzI7knIH43NmnrLOYeWwUlpJTX+V+qEIHPXtDWk i+S3TBIunng9amNi6owpSMAwGYmTOzTOg39UCXWUFCAs9mW/cRdQ9TrieNsVwozqYGMY ud38gNVy7hASRzjURWmOVrK8Lm1bGKmNLt/QqIPlK0Zbi79sDGl94Y4HvgRcvzJv2owV GO/6yFDyIZBlsfIr5xvExb4PHDGHZscKuenTgOys/I73OMjRL8cbQsLrUCTP+Fo1/Uy7 k13A== 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=o8LTeC4govd1fNBJO0ioJqcSmCWQfNIKLUUZIaiAhHg=; b=mYC+dP/WDJcpdUCufq6GqLT7I3XF4ZzfS3vmJHVP2p8OJlgU71Fi1SJoQ7xwuSEHHB 7BWm9jVslr73Z3O+jpo2HZ/Y/YITxjimy7P+CpVWqfhUXbDeWkXPcxvcrc7E4e2Jls3Z qHCNw8drs3HDVa+bYtfolT+RrRhKSZnIrJhzxJUN8wzvEyWbngZNBM4vhXR6HF8s2sxR EMR+tyiJq3NDbP1HiUBPVD9KOPNfcGzoki04umrZ+FraOjnGcMZMl4ldCCW2ZPVM+bBI gURdebAzlWnL2QAFEPuqAHqf9eaANWVVqA/4ks/J/rsxbt5+yrQ0z/EiMw2xlm9eE7ua GPvA== X-Gm-Message-State: APjAAAVcFaaKb5A62k6WZ+v5ya7JvxaeJ+WiBcfbdj9AuuJ+snAOdfnr nMP2eMLsi6KGoBXlVj1bipOQ5pPd2jXQ4Ebz+SkxTujA X-Received: by 2002:aca:eb09:: with SMTP id j9mr7724558oih.105.1568274096350; Thu, 12 Sep 2019 00:41:36 -0700 (PDT) MIME-Version: 1.0 References: <156821692280.2951081.18036584954940423225.stgit@dwillia2-desk3.amr.corp.intel.com> <156821693963.2951081.11214256396118531359.stgit@dwillia2-desk3.amr.corp.intel.com> <20190911184332.GL20699@kadam> <9132e214-9b57-07dc-7ee2-f6bc52e960c5@kernel.dk> In-Reply-To: <9132e214-9b57-07dc-7ee2-f6bc52e960c5@kernel.dk> From: Dan Williams Date: Thu, 12 Sep 2019 00:41:24 -0700 Message-ID: Subject: Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile To: Jens Axboe Cc: Dan Carpenter , Dave Jiang , ksummit , linux-nvdimm , Vishal Verma , Linux Kernel Mailing List , bpf@vger.kernel.org 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 Wed, Sep 11, 2019 at 3:11 PM Jens Axboe wrote: > > On 9/11/19 12:43 PM, Dan Carpenter wrote: > > On Wed, Sep 11, 2019 at 08:48:59AM -0700, Dan Williams wrote: > >> +Coding Style Addendum > >> +--------------------- > >> +libnvdimm expects multi-line statements to be double indented. I.e. > >> + > >> + if (x... > >> + && ...y) { > > > > That looks horrible and it causes a checkpatch warning. :( Why not > > do it the same way that everyone else does it. > > > > if (blah_blah_x && <-- && has to be on the first line for checkpatch > > blah_blah_y) { <-- [tab][space][space][space][space]blah > > > > Now all the conditions are aligned visually which makes it readable. > > They aren't aligned with the indent block so it's easy to tell the > > inside from the if condition. > > > > I kind of hate all this extra documentation because now everyone thinks > > they can invent new hoops to jump through. > > FWIW, I completely agree with Dan (Carpenter) here. I absolutely > dislike having these kinds of files, and with subsystems imposing weird > restrictions on style (like the quoted example, yuck). > > Additionally, it would seem saner to standardize rules around when > code is expected to hit the maintainers hands for kernel releases. Both > yours and Martins deals with that, there really shouldn't be the need > to have this specified in detail per sub-system. So this is *the* point of the exercise. I picked up this indentation habit a long while back in response to review feedback on a patch to a subsystem that formatted code this way. At the time CodingStyle did not contradict the maintainer's preference, so I adopted it across the board. Now I come to find that CodingStyle has settled on clang-format (in the last 15 months) as the new standard which is a much better answer to me than a manually specified style open to interpretation. I'll take a look at getting libnvdimm converted over. If we can take that further and standardize all of the places where contributors see variations across subsystems on the fundamental questions of style, timing, follow-up, and unit test invocation the Maintainer Entry Profile can be superseded with common guidelines. Otherwise, yes I completely agree with you that a "Maintainer Entry Profile" is a sad comment on the state of what contributors need to navigate, but that's today's reality that needs to be addressed.