<html><head><title>Replacing 9load (Editing Tue Dec 20 05:52:41 EST 2005 version)</title><META http-equiv="Content-Type" content="text/html; charset=utf-8"></head><!-- FFFFE9 is acme yellow; FFFFE9 is as close as you can get to it before charon decides to use  grey instead of map entry 254 --><body bgcolor="#FFFFE9" link="#0000AA" alink="#0000AA" vlink="#0000AA"><center><font size=+2><b>Replacing 9load</b></font> (Editing Tue Dec 20 05:52:41 EST 2005 version)</center><p> For information on editing, see thedescription of <a href="../0">Plan 9 wiki syntax</a>.<p><form action="/magic/wikipost" method="post"><table><tr><td valign=top><input type="submit" name="x" value="Put"></td><td><table><tr><td align=right>(optional) Comment:</td><td><input type="text" name="comment" value="" cols=40></td></tr><tr><td align=right>(optional) Email:</td><td><input type="text" name="author" value="" cols=40></td></tr></table><input type="hidden" name="title" value="Replacing 9load"><input type="hidden" name="version" value="1135075961"><input type="hidden" name="service" value="plan9"><input type="hidden" name="base" value="/wiki/plan9"><p><textarea name="text" wrap="virtual" cols="80" rows="25">! Date: Mon, 5 Dec 2005 15:47:14 -0500! From: Russ Cox <rsc@swtch.com>! To: 9fans <9fans@cse.psu.edu>! Subject: [9fans] replacing 9load For quite a few years, various of us have talked about replacing9load. When Jim and I replaced b.com with the combination of ld.comand 9load, we considered using a stock Plan 9 kernel instead. SeanQuinlan took a few steps toward making this possible: he added theconfiguration environment #ec, the Dev.shutdown routines, and/dev/reboot. With these, one can use the kernel as an impromptu bootloader already. I believe Ron Minnich does just that in some of hismachines. There are a few things 9load does that the kernel depends on. Themain one is loading plan9.ini from somewhere and leaving it inmemory. A secondary one is setting up the APM BIOS interface, and inthe original VESA code written for Inferno, 9load was responsible forsetting up the VGA. With the new realmode code (or better, if someonewould write it, VM86 code) in the kernel, the APM and VESA can bedone by the kernel proper. That leaves plan9.ini. Plan9.ini serves two related but different purposes. The first is togive the kernel hints about hardware recognition. The second is tospecify a few aspects of the software configuration. Ideally, itwould be nice if plan9.ini could become optional. Hardware recognition was a much bigger problem in the old ISA days.Plan9.ini was, at the time, an excellent alternative to recompilingthe kernel to hard-wire all the constants about your machine. Nowthat we have PCI and its device ids, you don't need to tell thekernel what hardware you have anymore. It knows, usually better thanyou. That leaves the software configuration: mouse, vga, serial console,kernel location, root file system location, boot menu, etc. The mouseand vga could possibly be auto-detected, and the new vga resize code(if it works) makes it possible to correct a bad guess about theuser's desired screen size. The other options in plan9.ini -- the serial console, the kernel androot file system, the boot menu -- can't just be guessed. Jim hasbeen playing with loading plan9.ini via PXE/TFTP, which is great fora real single-file-server Plan 9 setup, though it won't satisfy thesingle-machine users. I don't expect this part of plan9.ini to goaway, though one could make 9load do without it in the general case(scan the local 9fats for files named 9pc*, for example). When I put the new mmu code into the kernels, I didn't feel likeputting it into 9load too. Instead I wrote a small binary that turnsa gzipped kernel into a 9load binary that the PBS bootstrap couldload into memory. You run ! cat load 9pcload.gz >9load to produce a 9load from a kernel. I have put this in/n/sources/contrib/rsc/load. This new program means that you can build yourself a special pcloadkernel with some 9load-like user-level program installed as/boot/boot instead of the usual boot. It would find plan9.ini,present any prompts if needed, find and load a kernel, and then/dev/reboot into it. You could put dossrv, ext2srv, fossil, venti,kfs, factotum, mount, tftp, ftpfs, hget, etc., into the root filesystem, to load kernels off of any conceivable medium. While a new 9load using the real kernel could be great, it's not veryhigh on my or Jim's to do list, since the current 9load suffices, andwe're more interested in what happens once the kernel is in memorythan the mundane and now all-too-familiar details of the x86 bootprocess. I encourage those of you grumbling for a new 9load to attack one ofthe following problems:  *	write vm86 code for the kernel to replace the realmode code. vm86	code should be safer and more reliable and will make the vesa and	apm code run on more machines.  *	write a mouse auto-detector: scan the usb, try ps2, scan the	serial ports. this should be almost trivial.  *	write a vga size auto-detector: try aux/vga -m vesa -p and fetch	and parse the edid information from the monitor. aux/vga does most	of this already.  *	write a user-level program to be the `9load' in a 9pcload kernel.	the program should have generic "get me a plan9.ini" and "get me a	kernel" interfaces, like the current 9load, so that many boot	methods can be plugged in. Ironically, once this is all done we'll have moved full circle towhere Plan 9 was many years ago, when the hobbit boot loader was justa Plan 9 kernel with a different load address and a special bootprogram that let you set environment variables, examine memory,attach to file servers, run programs that were downloaded, and loadand boot a kernel. Russ </textarea><p></td></table></form> <hr><table width=100%><tr><td valign=center align=left></td><td valign=center align=right><a href="../about.html">About the server</a>| <a href="http://plan9.bell-labs.com/plan9"><img src="http://plan9.bell-labs.com/plan9/img/power36.gif"alt="Powered by Plan 9"></a></td></tr></table></html></body>