Re: [RFC] An idea for general kernel post-processing automation in FreeBSD

On 5/22/23 06:10, Rick Macklem wrote:
>>> Except that data is pathologically heterogeneous. There's nothing to sort
>>> in any meaningful way. And it's all about the runtime environment, which
>>> is impossible to know at build time (today we do it at run time). The linker
>>> hints file to know which of many things to load is almost optimal... Each
>>> file is different, especially for PCI, which is why we pre-process it once
>>> and put it into the linker hints.... So it's pretty good once the system is
>>> running, but at startup we parse it multiple times and likely would do more
>>> as we move more towards MINIMAL. It's been suggested that we move
>> BTW, if we are moving to MINIMAL (which I quite like), then with the
>> proposed approach we need to merge at least N + 1 lists, where N is the number
>> of modules.  Can the merge be done in place without incurring n**2
>> behaviour?
> I may not be understanding what you guys are discussing, but if you are
> referring to the merge done by sysinit_add(), then...
> 

Hi Rick,

> Right now, sysinit_add() just copies the contents of the two arrays into a
> new one.

That is correctly understood.

> Then I think the new one gets sorted again later? If the two
> lists being
> merged are already sorted,

Yes, that is correct. When two input lists are already sorted, they can 
quickly be merged into an output list, without any need for further sorting.

> then sysinit_add() could simply merge them,
> keeping them in order.

That is my proposal.

> 
> If what you are discussing isn't done by sysinit_add(), then just ignore the
> above.

sysinit_add() currently copies the content of the two arrays into a new 
one, similarly to memcpy(). I want to change that.

--HPS