William Frederick Jolitz and Lynne Greer Jolitz
This is the third article in this series, and at this point we feel it is important to examine just what we have accomplished so far. In our first article, we arrived at e sentially a "plan of action," outlining what we understand to be the important goals of our project, as well as discussing (as always, in hindsight) some of the important technical decisions made in the process of completing our successful port of BSD to the 80386. In the second article, we wrote three programs (using Turbo C and MASM) to prepare our host for the beginnings of this port by creating the basic tools. We are now at the point of departure, where the goal itself can become all-consuming. "Why all the drama?" one may ask. Well, what we are about to embark on may be considered, in a sense, like a mountaineering expedition to K2. We have done all the scheduling and planning and assembled the consumables and equipment. Now, here we sit at the base of the mountain, staring up at its intimidating peak and contemplating our first steps with both anticipation and dread. Projects of great complexity are always uncertain. In this case, our mountain is an empty 386 residing in protected mode. There is not one shred of code that we can rely on. One false step can cause a spontaneous reset, or worse yet, a hang. Please believe us when we say that it takes a lot of courage to take on such projects. Now one must shrug one's shoulders of any uncertainty and begin to place one foot in front of the other and scale the foothills. We must establish our base camp from which we can explore further. In this article, we endeavor to scale those foothills and establish our base camp by building upon our previous work; using our protected-mode program loader, we can create a minimal 80386 protected-mode standalone C programming environment for operating systems kernel development work. Next, we must write prototype code for various kernel hardware support facilities. Finally, we must use our standalone programming environment as a test bed to shake out the bugs in our first-cut implementation of kernel 386 machine-dependent code in preparation for incorporation in the BSD kernel. At this point, the neophyte tends to ask the question (and it is a good question, mind you) "Why spend so much time on small programs, prototype code, and the like, instead of getting into the hard stuff?" Yes, it does appear on the surface that one should start shoveling this huge operating system through the compiler and onto our host. (At this very instant of writing, the BSD kernel consists of 128,332 lines, according to wc -l, and supports roughly 150 Mbytes of user-level sources -- sorry, can't wait to consult wc on that!) Besides being a bit of a bore, just what would happen if we jumped into compiling code willy-nilly? In sum, it would be a complete disaster, as we would spread all of our latent bugs and misconceptions over a much broader body of code. Worse yet, all these different bugs would be well-distributed throughout our code and hence not easily differentiated or ordered. A simple beginning affords us the chance to find various bugs early, when the problem still has a chance of being resolved to our satisfaction. We have plenty of land mines to avoid as it is, without adding to our troubles.
|