From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756829AbcHBOkm (ORCPT ); Tue, 2 Aug 2016 10:40:42 -0400 Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:59440 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752947AbcHBOi4 (ORCPT ); Tue, 2 Aug 2016 10:38:56 -0400 Date: Tue, 2 Aug 2016 10:35:37 -0400 From: Rich Felker To: Greg KH Cc: Baole Ni , cmetcalf@mellanox.com, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, linux-kernel@vger.kernel.org, viresh.kumar@linaro.org, chuansheng.liu@intel.com Subject: Re: [PATCH 0029/1285] Replace numeric parameter like 0444 with macro Message-ID: <20160802143537.GT15995@brightrain.aerifal.cx> References: <20160802103537.15705-1-baolex.ni@intel.com> <20160802121617.GA23006@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160802121617.GA23006@kroah.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 02, 2016 at 02:16:17PM +0200, Greg KH wrote: > On Tue, Aug 02, 2016 at 06:35:37PM +0800, Baole Ni wrote: > > I find that the developers often just specified the numeric value > > when calling a macro which is defined with a parameter for access permission. > > As we know, these numeric value for access permission have had the corresponding macro, > > and that using macro can improve the robustness and readability of the code, > > thus, I suggest replacing the numeric parameter with the macro. > > > > Signed-off-by: Chuansheng Liu > > Signed-off-by: Baole Ni > > --- > > arch/tile/kernel/sysfs.c | 12 ++++++------ > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > diff --git a/arch/tile/kernel/sysfs.c b/arch/tile/kernel/sysfs.c > > index 825867c..cef3937 100644 > > --- a/arch/tile/kernel/sysfs.c > > +++ b/arch/tile/kernel/sysfs.c > > @@ -38,7 +38,7 @@ static ssize_t chip_width_show(struct device *dev, > > { > > return sprintf(page, "%u\n", smp_width); > > } > > -static DEVICE_ATTR(chip_width, 0444, chip_width_show, NULL); > > +static DEVICE_ATTR(chip_width, S_IRUSR | S_IRGRP | S_IROTH, chip_width_show, NULL); > > You do know about S_IRUGO, right? Why not use that? > > Same goes for your other replacements, use the correct #define, not a > mix of values | together. > > And you are sending hundreds of patches with the same identical subject > line, that's not ok, you need to make it unique for every patch. > Usually that is done with the subsystem and driver name, see examples of > this in the kernel changelogs. > > Please fix up and try again, in a much smaller series, before trying to > do this across the whole kernel tree. > > good luck! While I won't object to the parts I'm maintainer for if there's a general consensus this is an improvement, I don't think it's an improvement, even with S_IRUGO. It's a significant decrease in readability. Everybody who works on this code knows immediately and intuitively what 0444 means. I have to actually stop and think about what S_IRUGO means. >>From my perspective, these macros were a mistake from a time when standardization efforts wrongly thought of file permission mode values as "not a public interface". POSIX since corrected that (in the 2008 edition, from what I can tell); the specific values everybody expects are mandated. Rich