> 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. Understandable. I guess krtld must come before _locore_start because the latter is located in a loadable module and thus krtld is needed to load that module...? > > 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. I couldn't follow all the way through. Is krtld a self-contained module or are its functions and structures built into unix (or genunix)? > > 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.. >From below I understand that driver modules are automatically loaded (by >module name) when the os detects a PCI device id that is listed in >/etc/driver_aliases, thus driver loading is sort of dependent on >/etc/driver_aliases. But what about other modules? File systems and syscalls, >for example? I would like to understand when the kernel decides to load which >modules, why and how... > > 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. > > > The boot_archive is loaded by grub, dboot just > passes > the address of it on down to kobj_boot_mountroot(). Through the ramdisk_start and ramdisk_end properties, I suppose (usr/src/uts/common/krtld/bootrd.c, lines 89 and 91). Then it calls macro BRD_MOUNTROOT which is a call on a function pointer from a struct referred to by variable bfs_tab, which is defined in line 45 to be an array with UFS- and HSFS-specific FS ops structs (bufs_ops and bhsfs_ops -- boot UFS and boot HSFS, I suppose). Searching bufs_ops returns its definition in usr/src/common/fs/ufsops.c:835, which clearly is *not* located in usr/src/stand/lib/fs. What is the connection between usr/src/common/fs and usr/src/stand/lib/fs?
> 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. So, the boot archive is a pre-packaged UFS filesystem on a file, which is read from disk by the bootloader using BIOS code (or OBP code for SPARC, I guess), thus without the need to load specific OS drivers. In this filesystem, the drivers are found and loaded and only then is the OS able to read the disk by its own means (i.e. drivers). I suppose using the BIOS to read the disk even after the OS has been fully loaded is a performance issue or there are other limitations...? > > 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. Does this mean that, once files are loaded from the boot-archive, they don't actually need to be in the disk root fs? That is, can I remove a file from the disk if it is loaded from the boot-archive? I know, bootadm will need the file to be on the disk in the correct place to make the boot-archive anyway, but apart from this detail, is it possible to remove it? A corollary could be that to boot a very minimal OpenSolaris, all one needs is unix, genunix, kmdb, any drivers you want, a few /etc configuration files, a few /dev links and /devices folders, and the boot-archive. Is that right? I'm curious. Suppose for example that I wanted to create a custom Solaris distribution that only contains a single-user runlevel that drops me directly into ksh. Could I do that from the sources alone? > > 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. > > This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
