From owner-svn-src-head@freebsd.org Tue Oct 27 20:23:20 2020 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 99A114594E3; Tue, 27 Oct 2020 20:23:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CLNSS15cxz47yN; Tue, 27 Oct 2020 20:23:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 09RKN6Li013129 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 27 Oct 2020 22:23:10 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 09RKN6Li013129 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 09RKN68p013128; Tue, 27 Oct 2020 22:23:06 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 27 Oct 2020 22:23:06 +0200 From: Konstantin Belousov To: Ed Maste Cc: Hans Petter Selasky , src-committers , svn-src-all , svn-src-head Subject: Re: svn commit: r366993 - head/sys/net Message-ID: <20201027202306.GQ2643@kib.kiev.ua> References: <202010241023.09OANMcL075640@repo.freebsd.org> <20201024104628.GB2643@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4CLNSS15cxz47yN X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 20:23:20 -0000 On Tue, Oct 27, 2020 at 02:52:38PM -0400, Ed Maste wrote: > On Sat, 24 Oct 2020 at 06:46, Konstantin Belousov wrote: > > > > > -#include > > 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 is needed > for __FBSDID(), include it first. If either or > is needed, include it before other include files. > ( includes ; 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.