Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2526798imu; Sun, 23 Dec 2018 01:39:00 -0800 (PST) X-Google-Smtp-Source: ALg8bN51sD3AagxsGIctXjVG05HADHnvk5x5nfyQxpiRwqqOIRf8FdniHQbt95mdu5gjuas+3tiq X-Received: by 2002:a63:5455:: with SMTP id e21mr8738312pgm.316.1545557940294; Sun, 23 Dec 2018 01:39:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545557940; cv=none; d=google.com; s=arc-20160816; b=t2x+cwDVt++d+sQSxtKG0VMkhM5IqcIFKr34hwi+IJwWsEeVyNDyXgnMADgErX200u ALVyA6TKEfww/z4Mt3otFwyBMkN51KoVx0+seTVn/smfJR0fvvPguMwbRpaV1qoFD5uW hk6r9+n3Vu1h1eXgHsmt/w49NWYhp0omJm/cMXEZbWHffHWf7qzYpzMthGeJ4H1nlCCD eRarWqST3pRozdmMys3hiQc0cpC4lcb/dV67ZKt/Ad0TSNKPuc6zUunEY1Y2i9AwPIBJ 3jP3QKIv+pxmVr8MrjWfAU3+B5uY7kVUJxVpfwYHAgEwTCI8vmj2opHGfHOPIEO6RBVP C9Ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=Xa8YBftbit4LNU64bv2g0Ji6QGiSR3QswJ4spPgs5h8=; b=j2hymABPva+NCejI7vcvx/kiWQe16EYApMAXl1j4vnz4+aHhhm47GOydhJew1RvXat 4FFqjFBu2StrdyZdSOHuwfXSBaqJtHR8PbWmM1tbRUV5MOUszp5+OKkTKRRFU0dFk10O QQsO3t9QFyFy/axlqWJ/t681uMYp/at8d9D4Mi8DEUQINQElOpKjy9VQnPCpe0tr9Seb d25Hxm+WAbY6ML3TeKxWTBJXgP8czF9g2WCRIOaJ0hwk4/63VmgCHHHgCG3+BLBTKLzi FsuSBLafvhlQqkRzGNiJQ4Uc8YEutLZ16wQ+Kza4KR45jt4UiXeUmsPWhmc0O/33JOqb RHEQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ziepe.ca header.s=google header.b="Dr/HrLVs"; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g187si25381984pfc.43.2018.12.23.01.38.45; Sun, 23 Dec 2018 01:39:00 -0800 (PST) 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=@ziepe.ca header.s=google header.b="Dr/HrLVs"; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404036AbeLUXwe (ORCPT + 99 others); Fri, 21 Dec 2018 18:52:34 -0500 Received: from mail-pl1-f195.google.com ([209.85.214.195]:39805 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732613AbeLUXwe (ORCPT ); Fri, 21 Dec 2018 18:52:34 -0500 Received: by mail-pl1-f195.google.com with SMTP id 101so3149513pld.6 for ; Fri, 21 Dec 2018 15:52:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Xa8YBftbit4LNU64bv2g0Ji6QGiSR3QswJ4spPgs5h8=; b=Dr/HrLVsyJDciRZ3b6VzcvXivcuj7bTDCHFh7BkZ84RNzZAOmyBW+7+BqoipP6Wevk VMYy0d30/uBPD37UreftstG8zqPTtd/lyyASBdw31WD9HcfMjf3a/uKQG3HGK9BV1W4s FpIRz4A2MbKeP+Jvj0zvuAd2YDoYiBmbrt+Csa9kVRjvjbLtGOvjyAkw7FskK1T+j/B+ LIdWXpRN9t4sEYJvI1fFHt7WKdsq40OhA07EE9QudEaCrK2gHDgAfxXyWgcWANte1hoq BVwhWCrIFstqmm4v506IYvt0IqdKSNx8jWThoV2LBwj0CXGPUeuvvxplg02bxVgfJUBN 8rmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Xa8YBftbit4LNU64bv2g0Ji6QGiSR3QswJ4spPgs5h8=; b=EceKETpNDPj2bDi745X91pHkKBwEUYJxLtmxvB5Bccc/4xU45WCgJFofRfv0MV6N5k hLod5hY/QWIbfv/PJ04x9wj4UzI0h+CIxqMd9z6iP3/0QJc5L1wvqbQL2kSz2rl2HN6L 5k80u30refiLS5q/F1UOXwj2IYIBV2AyrKeJupHBuivHTPhHDOOPV3a77oWJgzlkBnbA oXmaMTOqobjGCfCIGcl4ZoZhYH5xFqijDJNm1JUlJGXAlcuMHwSnkuBIcixZuhPThfRC QFEA81wEloE9KqyIOEGvqv/OBdIY/vlEpWQDDu/h6fS0EmC5Fwv3VyumrpWqWXto2ulm A9Ew== X-Gm-Message-State: AJcUukd0eDBsJyodoZVOYt7vDqBS14/8L9PX69fe97/ldilE8xrhrfiJ T4jt83FUKikmh/DOwEKtC5/j4A== X-Received: by 2002:a17:902:bcc7:: with SMTP id o7mr4568107pls.281.1545436352687; Fri, 21 Dec 2018 15:52:32 -0800 (PST) Received: from ziepe.ca (S010614cc2056d97f.ed.shawcable.net. [174.3.196.123]) by smtp.gmail.com with ESMTPSA id 15sm35800446pfr.55.2018.12.21.15.52.31 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 21 Dec 2018 15:52:31 -0800 (PST) Received: from jgg by mlx.ziepe.ca with local (Exim 4.90_1) (envelope-from ) id 1gaUak-0006MP-PS; Fri, 21 Dec 2018 16:52:30 -0700 Date: Fri, 21 Dec 2018 16:52:30 -0700 From: Jason Gunthorpe To: Joe Perches Cc: Bart Van Assche , Stephen Warren , Tariq Toukan , xavier.huwei@huawei.com, netdev@vger.kernel.org, linux-rdma@vger.kernel.org, Doug Ledford , Stephen Warren , Christoph Hellwig , Andrew Morton , Linus Torvalds , Jonathan Corbet , linux-kernel@vger.kernel.org Subject: Re: rfc: bool structure members (was Re: [PATCH V3] net/mlx4: Get rid of page operation after dma_alloc_coherent) Message-ID: <20181221235230.GC13168@ziepe.ca> References: <20181219182031.8675-1-swarren@wwwdotorg.org> <20181220174318.GA21404@ziepe.ca> <20181220174448.GA21149@lst.de> <1545328145.185366.500.camel@acm.org> <072c2d9d187daf0672bf54ab035e47a05fd1cd1d.camel@perches.com> <20181221033159.GF23877@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 20, 2018 at 09:12:43PM -0800, Joe Perches wrote: > Care to submit a coding_style.rst patch or > improve the one below this? I took yours and revised it a little bit. I spent some time looking at assembly and decided to drop the performance note, the number of cases that run into overhead seems pretty small and probably already requires !! to be correct. There is also an equally unlikely gain, ie 'if (a & b)' optimizes a tiny bit better for bool types. I also added a small intro on bool, as I know some people are unfamiliar with C11 _Bool and might think bool is just '#define bool u8' (for those added to the cc) I'm looking at cases, like the patch that spawned this, where the struct has a single bool and no performance considerations. As CH said, seeing that get converted to int due to checkpatch is worse than having used bool. Using u8 won't make this struct smaller or faster. Cheers, Jason From c5e2c887f6326e1c4369876f39996417da5e90cc Mon Sep 17 00:00:00 2001 From: Jason Gunthorpe Date: Fri, 21 Dec 2018 16:29:22 -0700 Subject: [PATCH] coding-style: Clarify the expectations around bool There has been some confusion since checkpatch started warning about bool use in structures, and people have been avoiding using it. Many people feel there is still a legitimate place for bool in structures, so provide some guidance on bool usage derived from the entire thread that spawned the checkpatch warning. Link: https://lkml.kernel.org/r/CA+55aFwVZk1OfB9T2v014PTAKFhtVan_Zj2dOjnCy3x6E4UJfA@mail.gmail.com Signed-off-by: Joe Perches Signed-off-by: Jason Gunthorpe --- Documentation/process/coding-style.rst | 33 ++++++++++++++++++++++---- 1 file changed, 29 insertions(+), 4 deletions(-) diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst index 4e7c0a1c427a9a..efdb1d32035fe1 100644 --- a/Documentation/process/coding-style.rst +++ b/Documentation/process/coding-style.rst @@ -918,7 +918,32 @@ result. Typical examples would be functions that return pointers; they use NULL or the ERR_PTR mechanism to report failure. -17) Don't re-invent the kernel macros +17) Using bool +-------------- + +The Linux kernel uses the C11 standard for the bool type. bool values can only +evaluate to 0 or 1, and implicit or explicit conversion to bool automatically +converts the value to true or false. When using bool types the !! construction +is not needed, which eliminates a class of bugs. + +When working with bool values the true and false labels should be used instead +of 0 and 1. + +bool function return types, arguments and stack variables are always fine to +use whenever appropriate. Use of bool is encouraged to improve readability and +is often a better option than 'int' for storing boolean values. + +Do not use bool if cache line layout or size of the value matters, its size +and alignment varies based on the compiled architecture. Structures that are +optimized for alignment and size should not use bool. + +If a structure has many true/false values, consider consolidating them into a +bitfield with 1 bit members, or using an appropriate fixed width type, such as +u8. + +Otherwise limited use of bool in structures does improve readability. + +18) Don't re-invent the kernel macros ------------------------------------- The header file include/linux/kernel.h contains a number of macros that @@ -941,7 +966,7 @@ need them. Feel free to peruse that header file to see what else is already defined that you shouldn't reproduce in your code. -18) Editor modelines and other cruft +19) Editor modelines and other cruft ------------------------------------ Some editors can interpret configuration information embedded in source files, @@ -975,7 +1000,7 @@ own custom mode, or may have some other magic method for making indentation work correctly. -19) Inline assembly +20) Inline assembly ------------------- In architecture-specific code, you may need to use inline assembly to interface @@ -1007,7 +1032,7 @@ the next instruction in the assembly output: : /* outputs */ : /* inputs */ : /* clobbers */); -20) Conditional Compilation +21) Conditional Compilation --------------------------- Wherever possible, don't use preprocessor conditionals (#if, #ifdef) in .c -- 2.19.2