svn commit: r366993 - head/sys/net

[Konstantin Belousov]

On Tue, Oct 27, 2020 at 02:52:38PM -0400, Ed Maste wrote:
> On Sat, 24 Oct 2020 at 06:46, Konstantin Belousov <kostikbel at gmail.com> wrote:
> >
> > > -#include <sys/systm.h>
> > sys/systm.h should come right after sys/param.h.  These two headers are
> > exceptions to the normal alphabetical rule.
> 
> style(9) claims that sys/types.h and sys/param.h are the special headers:
> 
>      Kernel include files (sys/*.h) come first.  If <sys/cdefs.h> is needed
>      for __FBSDID(), include it first.  If either <sys/types.h> or
>      <sys/param.h> is needed, include it before other include files.
>      (<sys/param.h> includes <sys/types.h>; do not include both.) The
>      remaining kernel headers should be sorted alphabetically.
> 
> We should add sys/systm.h to style(9) as another special case if necessary.
Yes sys/systm.h is very special because it defines a lot of basic things,
like asserts, printf(9), and so on, and because it includes enough other
popular headers.  Its intent is to gather all common stuff, which makes
it both convenient and necessary to go before other (but sys/param.h is more
prioritized).

> 
> > > -infiniband_ipv4_multicast_map(uint32_t addr,
> > > -    const uint8_t *broadcast, uint8_t *buf)
> > > +infiniband_ipv4_multicast_map(
> > > +    uint32_t addr, const uint8_t *broadcast, uint8_t *buf)
> > And this is arguably regression, we fill line up to columns 72-80 before
> > splitting to the continuation line.
> 
> I agree with kib and arichardson has a clang-format fix for this in
> D26978. That said I can see an argument for it being easier to read
> with all function args on the same line.
> 
> > > -                             m = NULL;       /* mbuf is consumed by resolver */
> > > +                             m = NULL; /* mbuf is consumed by resolver */
> > This is a regression as well, in-line comment is typically preceeded by tab.
> 
> I suspect this is hard to do in an automated fashion in a way that's
> sensible overall (i.e., lining up inline comments on different lines).
> 
> This could be a case where we decide to just accept it when someone
> uses clang-format on new code, and just discourage sweeping
> clang-format changes on existing code.