From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966536AbcHBNVN (ORCPT ); Tue, 2 Aug 2016 09:21:13 -0400 Received: from nbfkord-smmo03.seg.att.com ([209.65.160.84]:35378 "EHLO nbfkord-smmo03.seg.att.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966397AbcHBNRq (ORCPT ); Tue, 2 Aug 2016 09:17:46 -0400 X-MXL-Hash: 57a09d794b9d39d0-c54b10ff94552bc13460f6f8be944028f694b3cb X-MXL-Hash: 57a0946a66ade49e-8e28254fb538fd7c8760b018eee6f0abea1a65a9 Subject: Re: [PATCH 0732/1285] Replace numeric parameter like 0444 with macro To: Baole Ni References: <20160802114053.30858-1-baolex.ni@intel.com> CC: , , , From: Edward Cree Message-ID: Date: Tue, 2 Aug 2016 13:34:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160802114053.30858-1-baolex.ni@intel.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.17.20.45] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.000.1202-22488.003 X-TM-AS-Result: No--12.500800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-AnalysisOut: [v=2.1 cv=OcWee0nY c=1 sm=1 tr=0 a=8P+NB+fYZDP74ap4g4d9Kw==] X-AnalysisOut: [:17 a=fVG4DLb5TBsA:10 a=IkcTkHD0fZMA:10 a=7z1cN_iqozsA:10 ] X-AnalysisOut: [a=QyXUC8HyAAAA:8 a=9rtSVq8FZCGNgOtZdSkA:9 a=QEXdDO2ut3YA:1] X-AnalysisOut: [0 a=avl4LiGQNoF5OB0DmCJ7:22] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [193.34.186.16] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/08/16 12:40, 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. NAK. To anyone with enough Unix experience to be contributing to the kernel, the octal values are *easier* to read: they're compact, and usually just take one of a few stereotyped values anyway (mostly 0444 or 0644). The macros are full of fluffy noise and take longer to read. (Also, if you're sending a 1,285-patch series, you should probably reconsider the choices that have brought you to this point.) -Ed > Signed-off-by: Chuansheng Liu > Signed-off-by: Baole Ni > --- > drivers/net/ethernet/sfc/ef10.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/ethernet/sfc/ef10.c b/drivers/net/ethernet/sfc/ef10.c > index 1f30912..fcf06c5 100644 > --- a/drivers/net/ethernet/sfc/ef10.c > +++ b/drivers/net/ethernet/sfc/ef10.c > @@ -275,9 +275,9 @@ static ssize_t efx_ef10_show_primary_flag(struct device *dev, > ? 1 : 0); > } > > -static DEVICE_ATTR(link_control_flag, 0444, efx_ef10_show_link_control_flag, > +static DEVICE_ATTR(link_control_flag, S_IRUSR | S_IRGRP | S_IROTH, efx_ef10_show_link_control_flag, > NULL); > -static DEVICE_ATTR(primary_flag, 0444, efx_ef10_show_primary_flag, NULL); > +static DEVICE_ATTR(primary_flag, S_IRUSR | S_IRGRP | S_IROTH, efx_ef10_show_primary_flag, NULL); > > static int efx_ef10_probe(struct efx_nic *efx) > {