Return to BSD News archive
Xref: sserve comp.unix.unixware:5862 comp.os.386bsd.development:2227 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!netnews.upenn.edu!newsserver.jvnc.net!news.cac.psu.edu!news.pop.psu.edu!psuvax1!news.ecn.bgu.edu!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!usc!nic-nac.CSU.net!charnel.ecst.csuchico.edu!xmission!u.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (Terry Lambert) Newsgroups: comp.unix.unixware,comp.os.386bsd.development Subject: Re: Fast boot required, can you help? Date: 2 Jun 1994 22:19:15 GMT Organization: Weber State University, Ogden, UT Lines: 121 Message-ID: <2sllt3$kcf@u.cc.utah.edu> References: <2s193b$2vg@search01.news.aol.com> NNTP-Posting-Host: cs.weber.edu In article <2s193b$2vg@search01.news.aol.com> glennfish@aol.com (Glenn Fish) writes: ] We have a customer that requires, for reasons that beg the ] imagination, the ability to boot their system (power up to ready for ] use) in 30 seconds, rather than 3-5 minutes. ] ] Got any suggestions? I've actually done this before, although I used a BSD variant as the test bed rather than SVR4, the principles the same. Here is a description of the BSD approach, which is almost exactly what would be needed for SVR4 as well (they are similar in their use of BIOS boot blocks, non-translated geometry protected mode disk drivers, X, memory overcommit -- BSD uses an improved Mach VM system, non-preallocated backing store. BSD does have quotas to prevent trashing the buffer cache in the most recent version, however). Terry's instant (re)boot(tm): Modifications are required to be rigidly followed: o Throw memory overcommit in the trash where it belongs. This solves the crash of binaries not related to the requesting process when memory runs out, it solves the crash of NFS mounted binaries (with a little hacking) that are run from images on a remotely mounted system when the remotely mounted systems image is modified, it solves the 8-10% performance hit of going through the vnode interface when swapping in non-modified text pages instead of going to raw disk, and it solves a number of situations that can cause the on disk shared library image to get trashed. o Preallocate swap backing store. This requires more swap to be allocated from available disk -- equal to the amount of memory on the system. This slightly increases the disk footprint if there is a lot of memory in the machine. o Insure that only specific processers are used. In most cases non-Intel parts can not be used for this, although some AMD and IBM parts will work. Cyrix parts will NOT work. The requirement is the ability to save and restore all processer registers, generaly through ICEBP (undocumented instruction -- see "The Undocumented PC" at your local bookseller), but also possible through power conservation instructions. o Establish per process (ideally) or per vnode (hack workaround) page quotas. This also coincidently solves the "linker eats the machine" problem and the "move mouse, wiggle cursor" problem caused by the cache being thrashed. o Modify the boot blocks to know about this kind of reboot. At the same time, modify the boot blocks to pass the BIOS apparent geometry (resulting from the INT 13, AH=8 call on devices 0x80 and 0x81) to the kernel and the kernel to store it. Also set the boot block signature to 0xAA55. These last two aren't needed for "instant reboot", but the geometry pass and a mod to the fdisk program will solve all but the non-linear geometry translation problem, and combined with a couple other mods, will allow the mounting of DOS partitions on second drives without needing a vtoc/disklabel and without the problems currently there. The 0xAA55 signature will allow the OS/2 boot manager to boot the OS with no problems (currently a problem). Might as well do both of those while you're in the boot code... o A hardware abstraction layer is needed to insure it is possible to restore state on things like the video adapter and keyboard; the serial port state and some other things, like current net connections, are either going to be a loss (and have to be handled as a "remote termination of connection" or otherwise gracefully let down). This will incidently make it known to the virtual video card what state the card is in at all times, making it possible to switch screens in and out of DOS graphics applications and making the @#$%! kernel debugger able to switch out of X on a panic instead of screwing up. Hmmm... that solves about 14 problems on top of providing new features... Procedure: 1) Reserve a memory hole for a reboot work area. 2) Save all current ram to backing store; save the full processer status. Write a flag field on the vtoc indicating this type of shutdown. 3) Save the regisaters; diddle the PC to show a start AFTER the halt instruction. 4) Tell the user to turn off the machine and Halt the processer. 5) When the machine comes back up, the modified boot block sees the signature, and reloads all of RAM and restores the processer state to the pre-save state, unsets the signature, and "returns" to a fake stack address to restart everything exactly where it left off. This is what the work area is for. What have we forgotten? Well, there will be a time jump of the duration of the shutdown. There has to be some way of preventing the screen saver from kicking in the instant the thing comes back up, and cron might be a little bit ticked; a bunch of alarms and timers will al go at once (their interval having elapsed) but that shouldn't be an issue. Anyway, the issues are solvable. Voila, instant boot, just add programmer. One crooked little dream I have is plugging a CDROM and a disk in, watching it grunk for 20 seconds or so, and *>PAF!*<, you're in an X based install utility, with pages pulled in as needed, the grunking being the kernel load, and the mouse pointer is sitting over the "accept defaults" button. The actual local hardware is inventoried in the background while the user reads the options in the dialog. A one-click install. Suck on that, NT. 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.