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