> On Sep 9, 2023, at 10:13 PM, Zhenlei Huang <z...@freebsd.org> wrote: > > > >> On Sep 8, 2023, at 2:19 AM, Brooks Davis <bro...@freebsd.org >> <mailto:bro...@freebsd.org>> wrote: >> >> On Wed, Sep 06, 2023 at 06:46:59PM -0700, Colin Percival wrote: >>> On 9/6/23 18:12, Zhenlei Huang wrote: >>>>> On Sep 7, 2023, at 2:37 AM, Colin Percival <cperc...@freebsd.org >>>>> <mailto:cperc...@freebsd.org>> wrote: >>>>> init_main: Record completed SYSINITs >>>>> >>>>> When removing them from sysinit_list, append them to sysinit_done_list; >>>>> print this list from 'show sysinit' along with the list of future >>>>> sysinits. >>>> >>>> So the `sysinit_done_list` is for DDB only. >>> >>> Well... sort of. You can open up kgdb and run 'p sysinit_done_list'. >>> >>>>> static STAILQ_HEAD(sysinitlist, sysinit) sysinit_list; >>>>> +static struct sysinitlist sysinit_done_list = >>>>> + STAILQ_HEAD_INITIALIZER(sysinit_done_list); >>>> >>>> Then it should be wrapped around with #ifdef DDB and #endif >>> I considered that, but since we're literally talking about 2 pointers of >>> memory I figured it wasn't worth making it conditional. >> >> IMO loss of the run order in a dump was a (minor) regression so this >> should be unconditionally available. > > No, we do NOT loss the run order. > > Given a kernel dump, we known its git commit hash, then the order of all > sysinit is determined, unless > we have non-stable sort of sysinits. > > That is somewhat not as flexible as previous sysinit array, or current > `sysinit_done_list`. > > So IMO `sysinit_done_list` is still useful only for debugging, either DDB or > kgdb.
Think about it twice. End user may have custom kernel config. It can be much useful when this system has buggy sysinit order (not caught during dev / test), then a `sysinit_done_list` can ease the debugging greatly. > >> >> -- Brooks > > Best regards, > Zhenlei
