Re: git: 1926d5cef6ea - main - init_main: Record completed SYSINITs

> On Sep 8, 2023, at 2:19 AM, Brooks Davis <brooks@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 <cperciva@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.

> 
> -- Brooks

Best regards,
Zhenlei