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

> On Sep 9, 2023, at 10:13 PM, Zhenlei Huang <zlei@FreeBSD.org> wrote:
> 
> 
> 
>> On Sep 8, 2023, at 2:19 AM, Brooks Davis <brooks@freebsd.org <mailto: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 <mailto: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.

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