Date: Tue, 27 Oct 2020 15:25:42 -0600 From: Warner Losh <imp@bsdimp.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Ed Maste <emaste@freebsd.org>, Hans Petter Selasky <hselasky@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r366993 - head/sys/net Message-ID: <CANCZdfoSLQN8VjQ1xkiGq1viHh8arg81p4CekhrGHMnwNGOD9Q@mail.gmail.com> In-Reply-To: <20201027202306.GQ2643@kib.kiev.ua> References: <202010241023.09OANMcL075640@repo.freebsd.org> <20201024104628.GB2643@kib.kiev.ua> <CAPyFy2D3y4F=e=qaPWCZZCjBUyMzF-Pb%2BZE-OtLEsrUR8cPmKA@mail.gmail.com> <20201027202306.GQ2643@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 27, 2020 at 2:23 PM Konstantin Belousov <kostikbel@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@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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoSLQN8VjQ1xkiGq1viHh8arg81p4CekhrGHMnwNGOD9Q>