> 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 :-)
It's historical. _locore_start was long ago the kernel entry point. Then krtld and modules were introduced, krtld had to happen before locore. More recently dboot was added and it happens before krtld. It hasn't been cleaned up, as the krtld stuff is currently common with sparc. Hopefully once sparc starts using boot_archives -- which is under way -- someone can do a little project to clean up this twisty startup path a bit. > > 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? Sort of, the only module that is initially loaded is 'genunix' (ok, and kmdb if you want it). Loading those is somewhat hard coded in kobj_boot(). The kernel can then initialize for a long time before loading any other modules. More on that below.. The unix / genunix split allows unix to hold platform specific code and genunix to have platform independent code. This is used a lot on sparc where there are many platforms. On x86 we've only had one platform in the past, but soon (with Xen) we'll have a 2nd platform on x86 too. > > 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. The boot_archive is loaded by grub, dboot just passes the address of it on down to kobj_boot_mountroot(). The code to read the "in memory" boot archive file systems is mostly under /usr/src/stand/lib/fs/... It lives in there because it used to be part of the multiboot program too. Moving it to somewhere under uts is a low priority thing someone could do. The boot_archive acts as a in memory read only root file system during early boot. We load device drivers and configuration files out of it. Why a boot archive? well GRUB uses BIOS to load the boot archive. BIOS can do that no matter what kind of disk device you have. The kernel then can probe what the disk/net controllers are present and load the appropriate device drivers out of the boot archive. It then can toss the boot_archive and use the real disk based root file system. The boot_archive contains a copy of a subset of directories from the real "/" filesystem. /boot/solaris/filelist.ramdisk (and /etc/boot/solaris/filelist.ramdisk) tell bootadm what files go in the archive. I'm not an expert in this part of the code, but basically /etc/driver_aliases tells the kernel how to map PCI device information into device driver names. A copy of driver_aliases and the device drivers are in the boot_archive. > > -- Douglas > > Message was edited by: > d3atiq This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
