> > 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...?
yes unix is just another partially relocated module in some ways. krtld gets to initialize almost first, so that genunix is loaded early and then things in unix can call things in genunix. That way very little code has to be aware about the unix/genunix split. For example, in developing the code for fakebop.c:_start(), I had to be careful to not invoke anything from genunix - as that doesn't work before krtld gets to run. krtld will also then know how to resolve references in later loaded modules against the symbols in unix. > > > > 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)? that depends. pre-build 57 krtld was always a distinct module. Now it's just linked into unix on x86, but still a distinct module on sparc. That's what the #define for _UNIX_KRTLD is about in kobj.c. The define exists for sparc, but not x86 currently. There is a project going on to switch sparc to use boot archives too. So shortly sparc will work much more like x86. > 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... I'm not that familiar with how other loadable modules are found - I've generally worked on lower level things that are always in unix or genunix. You can either go read the code (what I'd do), try google, or start a new thread with that question. modload() is the key function that loads a module, so searching for how/why it's called would be where I'd start. The Solaris Internals book, ISBN 0-13-148209-2, may be helpful for more generic questions like that. > > > > 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? ah .. you're right. I pointed you to the wrong directory. I'm not sure what stand/lib/fs is for. If you can't find where it's used, it may be used by some of SUN's internal diagnotistic tools and the source just tagged along into open solaris. "stand" is for "stand alone" (ie. no operating system required). it's for stuff like h/w diagnostics, boot loaders, etc. > 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...? Note -- there is no boot archive *yet* on sparc. Soon, but not yet. Sparc relies on OBP to go read the real disk (or network file server) for files during early boot. For x86, BIOS is a horribly slow way to read disk. Also sometimes we wind up getting root from devices which BIOS just can't get to. Diskless clients are an example. There's no requirement that the boot archive come from the same device as the final "/". > > > > 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? Almost. Before every poweroff or reboot a check is made to see if the boot_archive has gotten out of date (ie. you may have added a new file system or device driver). If you remove a device driver from the filesystem, I believe that bootadm may also remove it from the boot archive. If you really needed that driver, you'll have wrecked your system. > 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? yes -- there have been some experiments to create a minimal solaris distro which have done exactly this. See below... > 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? You could try that. Here is a now out-of-date blog entry where someone was doing something similar. http://blogs.sun.com/szhou/entry/build_a_minimal_solaris_image It pre-dates dboot and many other changes, so some of what he did no longer is necessary and some is just wrong now. This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
