Re: [PATCH 0029/1285] Replace numeric parameter like 0444 with macro

[Rich Felker <dalias@libc.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 <chuansheng.liu@intel.com>
> > Signed-off-by: Baole Ni <baolex.ni@intel.com>
> > ---
> >  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