Bill Studenmund wrote:

>On Tue, Nov 22, 2005 at 08:34:55PM -0800, Jason Thorpe wrote:
>  
>
>>On Nov 22, 2005, at 3:13 PM, Andrey Petrov wrote:
>>
>>    
>>
>>>It could be done by kernel linker(loader) so he'll be responsible  
>>>for module loading
>>>and initialization, and so it wouldn't be needed to code  
>>>dependiencies explicitly.
>>>      
>>>
>>Hmm... For things that would be loaded at run-time, that would work  
>>great... but not so well for things statically compiled into the  
>>kernel.  Though, a string-based dependency list for those things  
>>statically compiled in could be made to work, too.
>>    
>>
>
>It would be nice to pre-sort the list, say during kernel build. Since the 
>built-in ordering won't change from boot to boot, it will be a little 
>easier. We then only need the kernel to contain a routine to walk the 
>list and init in order; we won't need to embed the dependency-graph 
>builder in the kernel.
>
>Also, for built-in, I think it would be best to avoid coding the
>dependencies (the alternative I see to ordering). By "coding" I mean
>something where a module has a "make sure X is loaded" call or calls at
>its beginning. My concern is that with some dependnecy orders, we can end
>up gobbling up a lot of kernel stack and blow it, whereas with another
>order order the exact same modules load with little stack.
>  
>
I agree that having a module have to explicitly initialize its
dependencies is problematic.

I'd love to see a solution similiar to Solaris, where the dependencies
of a module are just named somewhere (in Solaris' case its in either a
well-known static variable defined in the module or some special ELF
section), and the kernel loader has to track which modules are loaded
and which ones it needs.

Doing this at run time is not hard, and while it does have a risk of
changing the calling order, the stack depth should be fixed, since you
aren't calling recursively.

For example, the list of dependencies could be named in a (new) CFATTACH
member.

Properly done, we could either automatically populate the dependency
list from the config file, or go the other way and eliminate the
dependency list from the config file syntax and derive it from the
source code.

    -- Garrett

>Say A depends on B, which depends on C, which depends on D, which depends 
>on E. If we init E, D, C, B, and A in that order, we only need one 
>routine's worth of stack at a time. If however we init'd A first, its 
>dependency verification would trigger B's init, which would trigger C's, 
>which would trigger D's, and then finally E's. So we have all five 
>routine's worth of stack active at once.
>
>Maybe we could bash rc.order to handle this during kernel build??
>
>Take care,
>
>Bill
>  
>


-- 
Garrett D'Amore                          http://www.tadpolecomputer.com/
Sr. Staff Engineer          Extending the Power of 64-bit UNIX Computing
Tadpole Computer, Inc.                             Phone: (951) 325-2134