On Thu, Jun 8, 2023 at 10:22 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > Hello all, > > Over the past few weeks, as time allowed, I've been working on adding > some automation to my Linux Kernel workflows. Most of this has been > scripting various maintainer tasks, e.g. reviewing and merging > patches, which I expect is not very interesting to most people reading > this, but I think there is one aspect of these automations that might > be interesting for a wider audience: basic patch sanity/verification > tests. These tests are intended to mimic the sanity tests I perform > when reviewing patch submissions, things like "run checkpatch", "make > sure it builds without error", "ensure the style/formatting is > reasonable", etc. For those that are curious, you can see the current > tests in the repo below, but I will caution you that there are surely > problems with the scripts, they are still very new and barely tested; > expect changes. I should also note that I haven't published the > tool/framework which I use to run these tests just yet, but the tests > are intended to be standalone so there should still be value as-is. > My thinking is that by sharing these scripts, and keeping them > updated, it will help keep the developers and reviewers sync'd as to > what is expected from a SELinux kernel patch. Much like checkpatch, I > don't expect these scripts to represent a perfect, ideal standard but > I think they represent a "good enough" example where the accepted > verification failures should be relatively few. > > * https://github.com/pcmoore/git-verification_scripts > > With all of the above in mind, I wanted to get everyone's opinions on > the style/formatting suggested by the scripts above. As anyone who > has looked at the SELinux kernel code knows, the style is somewhat > inconsistent, both with respect to the SELinux subsystem, and the > kernel as a whole. That unfortunately means that if we want to be > able to start vetting the style of new code changes, we really need to > properly (re)format the existing code first. Before I went too far > with this I wanted to see what it might look like when applied to one > of our ugliest source files, security/selinux/hooks.c; you can see the > results in the commit below: > > * https://github.com/pcmoore/misc-linux_kernel/commit/3f94fd77b46522a038eb6771b63d0a6d36ca3547 > > I'd like to hear what everyone thinks about making a change like this. > I personally think it is a positive step forward, but I do acknowledge > that those who have to do backports will likely feel some occasional > pain. As the backport pain will eventually subside, and the benefits > of nicer-looking code and improved/shared patch verification will > continue, I'm leaning towards reformatting the code, but I do *really* > want to hear what people have to say before we do this. > > Also, just in case you think I'm pushing my own crazy style ideas on > everyone, the scripts in the GitHub repo above actually leverages the > kernel's own clang-format configuration (with a minor tweak). > > * https://www.kernel.org/doc/html/next/process/clang-format.html > * https://github.com/pcmoore/git-verification_scripts/blob/main/configs/clang-format.d/clang-format.linux If you have any concerns regarding the style/formatting changes discussed above, please speak up soon. If I don't hear anything within the next few days I'm going to do ahead with the style fixes. -- paul-moore.com
