On Wed, Nov 26, 2025 at 07:45:51AM -0700, Warner Losh wrote: > On Wed, Nov 26, 2025 at 5:06 AM Konstantin Belousov <[email protected]> > 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 <[email protected]> > > > AuthorDate: 2025-11-25 16:10:23 +0000 > > > Commit: Warner Losh <[email protected]> > > > CommitDate: 2025-11-25 16:12:51 +0000 > > > > > > nvme: Minor style(9) fixes > > > > > > <sys/systm.h> needs to be first after <sys/param.h>. 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 <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.) Next, > include <sys/systm.h>, 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.
