Douglas Atique writes: > 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 "common" directory contains code that's compiled into two or more separate targets. See usr/src/stand/lib/fs/ufs/Makefile (for the ufs booter) and usr/src/uts/intel/Makefile.files. > 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). No boot archive on SPARC (yet), but that's otherwise fairly accurate. > 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...? Performance and context. > 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? Not really. Drivers can be unloaded from memory and then loaded back in on demand, and when they are reloaded, it'll be from disk. Plus, we need the ability to check the integrity of the boot archive and rebuild if necessary. I think removing files from the file system and having them in the archive alone may be _possible_, but I'm not sure it's a wise choice. You'd be skating on thin ice. > 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? Yes, but you're on your own. ;-} -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
