From nobody Wed Nov 26 15:01:00 2025 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dGjSG53zmz6J9lb; Wed, 26 Nov 2025 15:01:18 +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 4dGjSG1MDFz3LGY; Wed, 26 Nov 2025 15:01:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5AQF10Jb069647; Wed, 26 Nov 2025 17:01:03 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5AQF10Jb069647 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5AQF1051069646; Wed, 26 Nov 2025 17:01:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 26 Nov 2025 17:01:00 +0200 From: Konstantin Belousov To: Warner Losh Cc: Warner Losh , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 301b8a806f79 - main - nvme: Minor style(9) fixes Message-ID: References: <6925d6af.3b42c.336a0065@gitrepo.freebsd.org> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dGjSG1MDFz3LGY On Wed, Nov 26, 2025 at 07:45:51AM -0700, Warner Losh wrote: > On Wed, Nov 26, 2025 at 5:06 AM Konstantin Belousov > wrote: > > > On Tue, Nov 25, 2025 at 04:17:51PM +0000, Warner Losh wrote: > > > The branch main has been updated by imp: > > > > > > URL: > > https://cgit.FreeBSD.org/src/commit/?id=301b8a806f79292ee3324ca938a4d938df1911e8 > > > > > > commit 301b8a806f79292ee3324ca938a4d938df1911e8 > > > Author: Warner Losh > > > AuthorDate: 2025-11-25 16:10:23 +0000 > > > Commit: Warner Losh > > > CommitDate: 2025-11-25 16:12:51 +0000 > > > > > > nvme: Minor style(9) fixes > > > > > > needs to be first after . And we don't > > need > > > both sys/param.h and sys/types.h. > > > > We do not both sys/param.h and sys/systm.h as well, since sys/systm.h > > includes sys/param.h. > > > > Style(9): > Kernel include files (sys/*.h) come first. If either or > is needed, include it before other include files. > ( includes ; do not include both.) Next, > include , if needed. The remaining kernel headers should > be > sorted alphabetically. > > Should I update it to say just include systm.h over param.h over types.h? > Or is there some other rule to follow that we should document? A quick > survey suggests this is often the case, but a large minority of the time > both or even all three are included. I do not see why sys/systm.h alone is not enough. I.e., if sys/systm.h is included (first), then sys/param.h, sys/types.h, sys/queue.h and several others are not needed. This is really not matter of style, but a reasonable use of includes. We cannot remove any of these nested includes from sys/systm.h practically, so consumers can rely on it. > > However, in this case, I needed to keep it separate because nvme.h is > included by userland and I thought systm.h was kernel only (without > checking)... but systm.h does seem to have all the proper guards to make > that ok... Yes, I saw the #ifdef _KERNEL complications, but they are not.