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 <[email protected]> > > Signed-off-by: Baole Ni <[email protected]> > > --- > > 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
