On Tue, Aug 25, 2020 at 10:06 AM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > > On Tue, Aug 25, 2020 at 9:15 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > > On Fri, Aug 21, 2020 at 8:22 AM Stephen Smalley > > <stephen.smalley.work@xxxxxxxxx> wrote: > > > On Fri, Aug 21, 2020 at 4:36 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > > > > On Thu, Aug 20, 2020 at 4:19 PM Stephen Smalley > > > > <stephen.smalley.work@xxxxxxxxx> wrote: ... > > As I mentioned in the RCU patch thread, my preference at this point in > > time is to address this with comments and not pass the mutex into the > > security server. > > One alternative would be to move the mutex from selinux_fs_info to > selinux_state, at which point the mutex would already be accessible to > the security server code through the state parameters. This also > makes sense from the perspective that the mutex is already used to > synchronize not only selinuxfs-private state (e.g. pending bools) but > also policy changes. I think this will be needed anyway for the > patches to measure SELinux state because that call chain does not go > through selinuxfs and thus has no access to selinux_fs_info. That seems reasonable to me. > > > > Speaking about wrapping lines... I noticed only now that in this and > > > > earlier patches you align wrapped argument lists only by tabs (without > > > > extra spaces to align to the first argument). I'm not sure what is the > > > > preferred kernel style in this case, but I personally find the finely > > > > aligned argument lists much nicer to read (and I have always been > > > > aligning them like this in my patches). Obviously, I can't enforce my > > > > preferred style here, but I thought I'd raise this, since I had the > > > > impression we were trying to follow this style previously for new code > > > > (could be just confirmation bias on my part, though) and it might not > > > > have been your intention to change it (changed editor/settings?). > > > > > > I'm using the emacs mode settings from > > > Documentation/process/codingstyle.rst. I don't see anything in the > > > coding style document to suggest use of extra spaces for aligned > > > argument lists; if anything use of spaces rather than tabs for > > > indentation seems discouraged. I don't really care either way but > > > would like editor settings to ensure consistency. > > > > FWIW, my preference is for aligned argument lists, for example: > > > > void write_program(char *language, > > char *description); > > > > ... with the understanding that tabs are used as much as possible and > > that spaces are only used to make up the difference when the gap is > > less than a tab (8 chars). > > I don't suppose you have editor settings to help automate this? Not really, but some of that is simply because I tend to bounce around between editors depending on what type of work I'm doing. My fingers have more or less gotten used to it and do the right thing as a matter of habit these days. In the non-kernel projects I maintain there is a script which you can run that checks the formatting/style, and optionally fixes it for you (in the case of C, it's a wrapper around astyle); I lean on that a lot for those projects. It would be nice to have something like that here, but we would need to do a lot of style fixes first. I keep threatening to do that, but it never quite seems worth it; perhaps I should start doing that slowly. -- paul moore www.paul-moore.com
