I think the secret sauce with OpenFirmware lies in On Jan 3, 2011, at 9:30 PM, Andrew Gaylard <a...@computer.org> wrote:
> John, > > [ warning: somewhat off-topic ] > > On Mon, Jan 3, 2011 at 8:19 PM, John Zabroski <johnzabro...@gmail.com> 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 > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
