linux-kernel - Re: [PATCH 0290/1285] Replace numeric parameter like 0444 with macro

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 2 Aug 2016 15:31:50 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Baole Ni <baolex.ni@...el.com>
Cc:	dmitry.torokhov@...il.com, hal.rosenstock@...il.com,
	dledford@...hat.com, sean.hefty@...el.com, bp@...en8.de,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	haibo.chen@...escale.com, andrey.gelman@...pulab.co.il, afd@...com,
	javier@....samsung.com, chuansheng.liu@...el.com
Subject: Re: [PATCH 0290/1285] Replace numeric parameter like 0444 with macro

On Tue, Aug 02, 2016 at 06:57:11PM +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.

Please split these up and send them independently to the relevant
maintainers with sensible subject lines - a single 1000+ patch series is
far too large and you're CCing random people so it's hard to tell which
patches are relevant (for example the batch I'm replying to here are for
the input subsystem which I don't maintain so I'm not 100% sure why I'm
being copied here).

With this sort of thing it's often best to send one series per directory
or something similar.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)