On Jun 11, 3:27pm, dholland-tech%netbsd.org@localhost (David Holland) wrote:
-- Subject: Re: [clang-format] [NetBSD Style] Clarification regarding Include
| On Tue, Jun 11, 2019 at 07:49:33PM +0530, Manikishan Ghantasala wrote:
| > After discussing with my mentors @christos, @mgorny and some devs in
| > #netbsd-code IRC channel I came up with a draft of this order of Include
| > files,
| >
| > *<sys/param.h>* -- should come first.
| >
| > <sys/types.h> -- should come next
|
| In general .c files in the kernel should have either sys/param.h or
| sys/types.h first, but you don't need both. If both are present,
| though, it makes more sense for sys/types.h to be first, as roughly
| the first thing sys/param.h does is include it.
|
| Also, it's common for sys/cdefs.h to come before either. The only rule
| for it is that it must appear before anything (e.g. __BEGIN_DECLS)
| that depends on it.
|
| > <sys/ *.h> -- followed by <sys/ > block sorted alphdebitcal
| >
| > <net/ *.h> -- all blocks sorted alphabetical
| >
| > <netinet/ *.h>
| >
| > <protocols/ *.h>
|
| > There are some other includes such as *<uvm/ *.h> , <fs/ *.h>, <dev/
| > *.h> *which
| > are also kernel includes, should they be after *<sys/ *.> *?
|
| They should probably be sorted into the other non-sys/ kernel
| includes, like net*/. Especially if you're trying to write rules for
| some kind of order checker that isn't too smart.
|
| However, if you have more leeway than that, the "proper" order is to
| put infrastructure things before application things, which for the
| kernel means what you see in ffs_vnops.c: first a stack of sys/, then
| miscfs/, then ufs/ufs/, then ufs/ffs. (Why uvm/uvm.h comes after all
| of these (rather than between sys/ and miscfs/) I dunno.) And in say
| if_axe.c you'll see there's a stack of sys/, then net/, then dev/mii/,
| then generic dev/usb/, then its own header. And when you find
| machine/ in a .c file, it's usually towards the end; but in kernel
| includes, that varies.
>From a dependencies perspective I think it should be:
<sys/*> kernel headers
<uvm/*> vm headers
<net*/*> network protocol headers
<*fs/*> filesystem headers
<dev/*> device driver headers
the question is what to do with:
<machine/*>
<[arch]/*>
I think machine/* should not be included directly (and use the <sys/*>
or <uvm/*> header instead if one exists), and that <machine/*> should
be preferred over <[arch]/*> and these should be included last.
christos