svn commit: r366993 - head/sys/net

Warner Losh imp at bsdimp.com
Tue Oct 27 21:25:55 UTC 2020


On Tue, Oct 27, 2020 at 2:23 PM Konstantin Belousov <kostikbel at gmail.com>
wrote:

> 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).
>

So sorted after sys/types.h or sys/param.h should be documented in style(9).

https://reviews.freebsd.org/D26981

has a proposed change.

Warner


> >
> > > > -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.
>


More information about the svn-src-all mailing list