> To get from dboot into the rest of unix, dboot turns
> on virtual memory
> and jumps to the kernel entry point which is always
> just the first instruction
> at the load address of the kernel text. That's always
> i86pc/ml/locore.s - which
> starts with:
>         /*
> * The very first thing in the kernel's text segment
>  must be a jump
>         * to the os/fakebop.c startup code.
>  */
>        .text
>  jmp     _start

> 
> You'll find _start written in C in
> usr/src/uts/i86pc/fakebop.c.
> From there on out it's mostly written in C and not
> too hard to
> follow.

Ok. _start does a lot of bookkeeping (i.e. kernel structures setup -- sorry for 
generic terminology :-) and calls _kobj_boot, which does more initialization 
and calls kobj_init (we are now in the kernel runtime linker, krtld), which 
does more initialisation and then exitto (would that be some kind of jmp 
disguised as a never-returning C function?) an address pointed to by variable 
entry, which happens to have been initialised in _kobj_boot to the entry of 
_locore_start
(       bootaux[BA_ENTRY].ba_ptr = (void *)_locore_start;)
I imagine there might be a reason for this zigzagging between C and assembly 
and this myriad of function pointers being called everywhere, though this is 
too much for me to digest at once :-)

>From theory I read somewhere around, krtld is the "backplane" where kernel 
>modules get dynamically loaded, so I have explored the code that sets the 
>stage to this module loading. I guess module loading is then carried on as per 
>some configuration file, but I wonder which file that would be. Any hints?

As a side topic, I am also struggling to understand how the ramdisk (can I also 
call it the boot-archive?), which gets passed to dboot by grub through the 
module command in menu.lst, gets loaded by unix and what it is used for. Could 
it be related to the kobj_boot_mountroot() function? I would appreciate some 
guidance to the code in this respect too.

-- Douglas
 
 
This message posted from opensolaris.org
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to