On Tue, Aug 11, 2026 at 02:40:59PM +0000, Gleb Smirnoff wrote:
> The branch main has been updated by glebius:
>
> URL:
> https://cgit.FreeBSD.org/src/commit/?id=662497d5a7415f8779b7be03e39f66eb8419174d
>
> commit 662497d5a7415f8779b7be03e39f66eb8419174d
> Author: Gleb Smirnoff <[email protected]>
> AuthorDate: 2026-08-11 14:39:30 +0000
> Commit: Gleb Smirnoff <[email protected]>
> CommitDate: 2026-08-11 14:39:30 +0000
>
> SYSINIT: add explicit SI_ORDER_LAST
>
> Working on cleansing use of (SI_SUB_FOO + 1) construct through the kernel
> I found a repeating pattern. Often a developer adds a module that depends
> on certain subsystem to be fully instantiated and they want to put their
> module SYSINIT right at the end of the SI_SUB_FOO. Such module usually
> expects that nothing else within this subsystem shall depend on the
> module.
>
> The problem with SI_ORDER_ANY which practically was "the last" until this
> change is that it is used very widely and people treat it literally as
> "any", well, because this is what the name says. This lead to many parts
> that could have dependencies later to be added as SI_ORDER_ANY.
>
> So, our developer with the new subsystem that depends on SI_SUB_FOO has
> three options:
>
> 1) Use SI_ORDER_ANY, but grep around ther kernel for other SI_SUB_FOO
> entries to make sure that no dependencies are set to SI_ORDER_ANY. And in
> case they are, shift them up and recheck if dependencies of those
> dependencies are met.
>
> 2) Take next subsystem in sysinit list. However, the next one can be
> SI_SUB_BAR, that is completely irrelevant from SI_SUB_FOO, and our
> developer doesn't want to put his module's SYSINIT into SI_SUB_BAR, cause
> it is ugly.
>
> 3) Use the (SI_SUB_FOO + 1) construct that violates -Werror=assign-enum.
>
> The SI_ORDER_LAST solves this hard choice. If you know that nothing is
> going to depend on your module within SI_SUB_FOO, but you depend on
> SI_SUB_FOO, just use SI_ORDER_LAST.
Given that SI_ORDER_LAST isn't UINT_MAX, should we have an assert like
the one below so LAST continues to be last?
-- Brooks
diff --git a/sys/kern/init_main.c b/sys/kern/init_main.c
index 8cbdd645a230..9825b71a746e 100644
--- a/sys/kern/init_main.c
+++ b/sys/kern/init_main.c
@@ -200,8 +200,10 @@ sysinit_mklist(struct sysinitlist *list, struct
sysinit **set,
TSENTER();
TSENTER2("listify");
STAILQ_INIT(list);
- for (sipp = set; sipp < set_end; sipp++)
+ for (sipp = set; sipp < set_end; sipp++) {
+ MPASS((*sipp)->order <= SI_ORDER_LAST);
STAILQ_INSERT_TAIL(list, *sipp, next);
+ }
TSEXIT2("listify");
TSENTER2("mergesort");
STAILQ_MERGESORT(list, NULL, sysinit_compar, sysinit, next);
