John, [ warning: somewhat off-topic ]
On Mon, Jan 3, 2011 at 8:19 PM, John Zabroski <[email protected]> wrote: > Kind of a tangent, but something that has bugged me about the Alto and > pretty much every modern machine since is the ad-hoc design of the bootstrap > mechanism for fetching the machine image from somewhere on the network. > > In moderm machines, the bootstrap is pretty primitive and something like > pxeboot. Redhat has hired hoardes of programmers to build tools to support > this process, which is really just a testimony to how ad-hoc the tool chain > is; how do we know when Redhat has perfected the process? What design > wisdom is there to suggest that the Alto was in any way better? I can't speak about the Alto, but OpenFirmware [1] is an excellent way to bootstrap a system. Modern PCs offer brilliant performance at an affordable price, but the BIOS remains terribly primitive, even with PXE. I haven't seen (U)EFI, so I can't comment on it. The trouble with bootstrap firmware is that, as people think of more things they'd like to do at install-/boot-time, so the code size and complexity grows. For instance, suppose that we limit the PROM functionality to "just (a) provide a console interface, and (b) be able to load an image (kernel) and run it". We decide that we'd like load images over a serial port (simplest thing possible). So we need something like xmodem to transfer it. That's pretty minimal, so we're looking good. Then we get smart: why not allow an IP link over the serial port? So we add PPP, UDP, and TFTP All this needs configuration information, so we need a way to edit and store the settings (IP address of the TFTP server, etc.), and we need a second serial port for the console. Then it'd be nice to be able to ping the computer to confirm the PPP link's up, so we add ICMP. Then we realise that TFTP is slow due to network latency (no sliding window). So we add TCP. Now we can boot images via a http:// URLs. That's cool. But we'd like to be able to resolve names, to avoid having IP numbers in URLs. So we add a DNS resolver. But that requires a new setting: nameserver. Then we realise that it'd be pretty easy to extend the console interface to work over TCP too, so we add a telnet server. Now we don't need a physical console on the machine, so that's also cool. Then someone complains that http and telnet are insecure, so we change to https and ssh. That means the SSL PKI libraries. Then we'd like IPv6. ... you get the picture. Before long, the PROM *is* a whole OS. So one of the reasons I like OpenFirmware is that it's a reasonable balance between having too little capability (the BIOS), and too much (the example above). Another is that it's completely programmable (FORTH) by the user. Also, it's extensible, so add-in cards can contain their own code to extend the base functionality. So a USB interface card could contain code to explain to the PROM that it is a bus that needs walking, that certain bus devices are bootable (disks, memory sticks), and others can be console I/O (serial). The basic firmware never needs a USB protocol stack; it only needs to know the properties of console and block devices. Lastly, it's bytecoded, so it's independent of CPU architecture. - Andrew [1] http://en.wikipedia.org/wiki/IEEE1275 _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
