From: Joe Perches <joe@perches.com> Date: 2018-03-26 20:29:01
drivers/hwmon is the most frequent user of symbolic permissions
like S_IRUGO in the kernel tree.
$ git grep -w -P "S_[A-Z]{5,5}" | \
cut -f1 -d: | cut -f1-2 -d"/" | sed -r 's/[A-Za-z0-9_-]+\.[ch]$//' | \
sort | uniq -c | sort -rn | head
3862 drivers/hwmon
814 drivers/scsi
763 drivers/net
242 drivers/infiniband
184 drivers/staging
181 drivers/usb
158 fs/proc
150 fs/xfs
148 fs/
142 drivers/misc
But using octal and not symbolic permissions is preferred by many
as it can be more readable.
https://lkml.org/lkml/2016/8/2/1945
Rather than converting these piecemeal, perhaps just do them all
at once via a trivial script like the below:
$ git grep -w -P --name-only "S_[A-Z]{5,5}" drivers/hwmon | \
xargs ./scripts/checkpatch.pl -f --types=symbolic_perms --fix-inplace
$ git grep -w -P --name-only "S_[A-Z]{5,5}" drivers/hwmon | \
xargs ./scripts/checkpatch.pl -f --types=symbolic_perms --fix-inplace
It's run twice because checkpatch only does 1 conversion per line
and there are some multiple instance lines.
This currently results in a 669 KB patch which is too large
to post but can be easily generated when appropriate.
drivers/hwmon is the most frequent user of symbolic permissions
like S_IRUGO in the kernel tree.
$ git grep -w -P "S_[A-Z]{5,5}" | \
cut -f1 -d: | cut -f1-2 -d"/" | sed -r 's/[A-Za-z0-9_-]+\.[ch]$//' | \
sort | uniq -c | sort -rn | head
3862 drivers/hwmon
814 drivers/scsi
763 drivers/net
242 drivers/infiniband
184 drivers/staging
181 drivers/usb
158 fs/proc
150 fs/xfs
148 fs/
142 drivers/misc
But using octal and not symbolic permissions is preferred by many
as it can be more readable.
https://lkml.org/lkml/2016/8/2/1945
Rather than converting these piecemeal, perhaps just do them all
at once via a trivial script like the below:
$ git grep -w -P --name-only "S_[A-Z]{5,5}" drivers/hwmon | \
xargs ./scripts/checkpatch.pl -f --types=symbolic_perms --fix-inplace
$ git grep -w -P --name-only "S_[A-Z]{5,5}" drivers/hwmon | \
xargs ./scripts/checkpatch.pl -f --types=symbolic_perms --fix-inplace
It's run twice because checkpatch only does 1 conversion per line
and there are some multiple instance lines.
This currently results in a 669 KB patch which is too large
to post but can be easily generated when appropriate.
I have something similar using coccinelle, which has the added benefit
of also adjusting multi-line alignments. But then I am hesitant to pull
it in because I don't really see the point. A more intelligent approach
would be to convert hwmon drivers to the latest API, and/or to introduce
more intelligent macros such as SENSOR_DEVICE_ATTR_{RO,RW,WO}. But that
would require active work as well as reviewers, and especially the latter
is extremely difficult if not impossible to find for the hwmon subsystem.
Since the hwmon subsystem has been labeled as both "obsolete" and "obscure",
that is maybe not entirely surprising, and I think we are good as we are.
I am happy to accept patches updating permissions as other changes are made
to a file, but I don't see a pressing need to change all files just to make
statistics happy (and backports more difficult).
Guenter
From: Joe Perches <joe@perches.com> Date: 2018-03-27 06:52:10
On Mon, 2018-03-26 at 23:33 -0700, Guenter Roeck wrote:
On 03/26/2018 01:28 PM, Joe Perches wrote:
quoted
drivers/hwmon is the most frequent user of symbolic permissions
like S_IRUGO in the kernel tree.
[]
I have something similar using coccinelle,
Please post the script.
I expect it doesn't work quite the same as checkpatch.
which has the added benefit
of also adjusting multi-line alignments.
That's a benefit, but it's makes it difficult to review.
I also have the same patch rewrap alignment post this
automated patch, done with emacs formatting.
This patch is somewhat simpler to review which is why
it's not sent along with this script.
But then I am hesitant to pull
it in because I don't really see the point. A more intelligent approach
would be to convert hwmon drivers to the latest API, and/or to introduce
more intelligent macros such as SENSOR_DEVICE_ATTR_{RO,RW,WO}.
Another approach would be to separate the const bits
from the non-const bits to reduce data.
But that
would require active work as well as reviewers, and especially the latter
is extremely difficult if not impossible to find for the hwmon subsystem.
[]
Since the hwmon subsystem has been labeled as both "obsolete" and "obscure",
that is maybe not entirely surprising, and I think we are good as we are.
Maybe true.
I am happy to accept patches updating permissions as other changes are made
to a file, but I don't see a pressing need to change all files just to make
statistics happy (and backports more difficult).
Not sure backports are a real issue.
If it were a real issue, the updated permissions are noise
and shouldn't be accepted for the other changes.
From: Joe Perches <joe@perches.com> Date: 2018-03-27 11:48:11
On Tue, 2018-03-27 at 03:28 -0700, Guenter Roeck wrote:
On 03/27/2018 12:35 AM, Joe Perches wrote:
quoted
On Mon, 2018-03-26 at 23:33 -0700, Guenter Roeck wrote:
quoted
Since the hwmon subsystem has been labeled as both "obsolete" and "obscure",
fyi: It's marked Maintained in MAINTAINERS
I did not say that it was not maintained, and I am aware of the information
in the MAINTAINERS file, thanks.
As am I.
I do agree that hwmon is obscure. Almost everything about
anything is obscure to those that don't fully understand it.
I am unaware though of any use of "obsolete" in drivers/hwmon/
or in Documentation/ about hwmon or the wiki/
In what sense do you mean hwmon is obsolete?
And the cocci script?
Anything later than:
https://systeme.lip6.fr/pipermail/cocci/2016-December/003887.htmlhttps://github.com/groeck/coccinelle-patches/tree/master/hwmon
?
btw: I think the perl scripts I posted for DEV_ATTR_<RW|RO|WO>
transforms are simpler and less prone to tool versioning
issues.
https://lkml.org/lkml/2017/12/22/844
It'd be fairly simple to add SENSOR_ support.
On Tue, 2018-03-27 at 03:28 -0700, Guenter Roeck wrote:
quoted
On 03/27/2018 12:35 AM, Joe Perches wrote:
quoted
On Mon, 2018-03-26 at 23:33 -0700, Guenter Roeck wrote:
quoted
Since the hwmon subsystem has been labeled as both "obsolete" and "obscure",
fyi: It's marked Maintained in MAINTAINERS
I did not say that it was not maintained, and I am aware of the information
in the MAINTAINERS file, thanks.
As am I.
I do agree that hwmon is obscure. Almost everything about
anything is obscure to those that don't fully understand it.
I am unaware though of any use of "obsolete" in drivers/hwmon/
or in Documentation/ about hwmon or the wiki/
In what sense do you mean hwmon is obsolete?
_I_ did not say it was obsolete. It was described as obsolete by a maintainer
of a different subsystem at a conference a couple of years ago. If I wasn't too
lazy, I could try to find the presentation, but I don't see the point.
I don't think I ever published it. If I recall correctly, it required
some cleanup patches to be applied first, but then I gave up on the idea
because I didn't want to proceed without code reviews.
btw: I think the perl scripts I posted for DEV_ATTR_<RW|RO|WO>
transforms are simpler and less prone to tool versioning
issues.
https://lkml.org/lkml/2017/12/22/844
It'd be fairly simple to add SENSOR_ support.
From: Joe Perches <joe@perches.com> Date: 2018-03-27 16:52:58
On Tue, 2018-03-27 at 08:44 -0700, Guenter Roeck wrote:
On 03/27/2018 04:48 AM, Joe Perches wrote:
quoted
On Tue, 2018-03-27 at 03:28 -0700, Guenter Roeck wrote:
quoted
On 03/27/2018 12:35 AM, Joe Perches wrote:
quoted
On Mon, 2018-03-26 at 23:33 -0700, Guenter Roeck wrote:
quoted
Since the hwmon subsystem has been labeled as both "obsolete" and "obscure",
[]
quoted
In what sense do you mean hwmon is obsolete?
[]
_I_ did not say it was obsolete. It was described as obsolete by a maintainer
of a different subsystem at a conference a couple of years ago. If I wasn't too
lazy, I could try to find the presentation, but I don't see the point.
Then it seems you were just being obscure on purpose.
You wrote obsolete without context.
cheers, Joe