D'oh, I love touch screens. What I tried to say was that OF is mostly just Forth, and I think that was what made it so lovely to work with.
It was nice to be able, for example, to interactively troubleshoot PPC based Mac hardware using Open Firmware. I seem to be having some trouble articulating the thought, but I think it really jibes with the idea that an operating system is a collection of things that don't fit into a language (paraphrasing Design Principles Behind Smalltalk.) It dawns on me that if you only include the barest essentials, it's not hard to have the box pull the rest of it's "not-so-firm" ware from the network, even redefine assumptions about what the firmware should and shouldn't do. I'm picturing something like the Maru bootstrap, where one simply defines ones (lisp, forth, what have you) in firmware, but only for bootstrapping it's replacement (which may salt the implementation to taste) on boot... Or perhaps I'm repeating something that's already been said or is obvious? It seems as though soft and firm might converge. On Jan 3, 2011, at 9:30 PM, Andrew Gaylard <[email protected]> wrote: > 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 _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
