Porting Unix to the 386: Research & the Commercial Sector
Where does BSD fit in?"The time has come," the Walrus said, "To talk of many things: Of shoes--and ships--and sealing wax-- Of cabbages--and kings--And why the sea is boiling hot-- And whether pigs have wings." --Lewis Carroll
At this point in our article series, the basic toolset for 386BSD development is in place, and we're ready to begin the job of porting the kernel program. (Or to use the mountain-climbing analogy we've followed until now, we've completed the preliminaries and are ready to begin scaling the peak.) With this in mind, it's a good time to pause and consider where we've been and where we are going.
We've discovered over the course of this series that there is considerable confusion and debate among researchers, programmers, businesses, and other interests over the nature and role played in the computer industry by Berkeley UNIX in general and by 386BSD in particular. This is not surprising, given the direction of operating systems in the commercial sector such as AT&T's System V, Release 4, Apple's System 7, IBM/Microsoft OS/2, and others. As such, it has become crucial to differentiate these two sectors, examine the differing motivations and goals, and discuss some of the trends that will eventually tie these two worlds together.
The most important thing to remember about Berkeley UNIX is that it is and will remain a "research" project. This means it is not designed with the needs of the commercial sector in mind -- the University of California is not a development shop such as the SCOs of the world. BSD provides, in essence, the opportunity for operating systems, applications, networks, and other areas to evolve beyond the current requirements of the commercial sector to produce the technology required for next stage efforts. This is a demand of research -- to get on with new work and not simply stagnate.
Commercial operating systems releases have a far different agenda, however. While much of it is self-serving (such as ABI, which we think should actually stand for "AT&T Binary Intolerance"), there is a method to the madness. Commercial releases are tied to the past. In fact, the tie is so strong that even when there is a critical need to offload some past burdens, a company finds it politically impossible to do so. We are reminded of Fred Brooks's classic work, The Mythical Man-Month (Addison-Wesley, 1975), and his discussion of the infamous (but popular) IBM OS/360 operating system. This operating system grew bigger and bigger and bigger in order to meet the perceived demands of their customers. And as it grew bigger, the number of bugs grew as well (though not at the same rate). As Brooks reflects on this project, he pinpoints a key issue (page 122 - 123):
Lehman and Belady have studied the history of successive releases in a large operating system. They find that the total number of modules increases linearly with release number, but that the number of modules affected increases exponentially with release number. All repairs tend to destroy the structure, to increase the entropy and disorder of the system. Less and less effort is spent on fixing original design flaws; more and more is spent on fixing flaws introduced by earlier fixes. As time passes, the system becomes less and less well-ordered. Sooner or later the fixing ceases to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress. Furthermore, machines change, configurations change, and user requirements change, so the system is not in fact usable forever. A brand-new, from-the-ground-up redesign is necessary.
In sum, it might have been simpler to abandon further work on this titanic system (400K of assembler code, a princely sum at the time) and go on to new operating systems.
Because of its research agenda, Berkeley UNIX is less concerned with issues such as ABI. Applications interfaces are quite properly handled outside the kernel, usually with a library. Eventually, antiquated or nonstandard interfaces are brought up to speed with newer technology, and programmers use the library less and less, until finally most delete it from their world. Researchers cannot afford to work with bloated kernels, stuffed full of arcane and inappropriate software. Research operating systems must be lean, mean computing machines.
So, while everyone longs for the latest innovation, the BSD Maserati, not everyone feels comfortable with the incredible power it provides -- not everyone is a race car driver any more than everyone is an operating systems programmer. BSD provides the mechanism for tremendous new opportunities, but it doesn't have a lot of safety nets. You can just as easily crash and burn with BSD, and have no one to blame but yourself.
Commercial systems vendors offer customers a nice, big, memory-guzzling Oldsmobile of an operating system ("This is your father's operating system") with all the same features everyone has seen since childhood. And when in doubt, more is added in the kernel until everyone is satisfied. Because they do not want to increase support overhead, vendors try to prevent "crash and burn" occurrences by making it so safe that you are protected from yourself (and, by the way, if you do circumvent the controls, you can't blame them--they tried to save you). At least, this is the intent: Give the customers what they want (within reason and while maintaining control) and try to minimize support headaches.
We said in January that "because standards by accumulation just don't work, we strive in 386BSD to avoid such nonsense." This was not an idle statement, but a cornerstone of our specification. We are not the first to observe the problems that arise when bloated kernels become a mainstay of either research or commercial offerings (as Fred Brooks discussed in his book). In several current commercial offerings, the complexity has become so great that the kernels have become difficult to maintain and impossible to orient toward the future. Customers lose what they so desperately desire in an expensive commercial release, namely bug-free software and timely support. This trade-off for flexible and innovative systems is beginning, like OS/360, to sink under its own weight.
It's ironic that this would happen to UNIX, which was predicated on the essentially "minimalist" work of Thompson and Ritchie. This problem is not restricted to the commercial sector, however. In fact, one reason many are less than enamored with MACH is that its "microkernel" is roughly comparable in size to the 386BSD kernel -- and yet it requires much more memory to be useful.
The final question now becomes, "What do I use now?" For the user dependent on a proprietary database or accounting software, the answer is quite simple -- just continue using what you have been using. Unless there is a compelling reason to invest in new technology, you just disrupt your business and your workers for no good reason. Eventually, some aspects of Berkeley UNIX will be integrated into commercial (and other research) releases, but don't anticipate it soon.
For those who must look to the future, however, such as applications, networking, and operating systems designers, Berkeley UNIX will continue to be a source of the innovative new technology required for new products and new functionality in a competitive world economy. Businesses and programmers should keep themselves current with these research trends, for ready incorporation in the commercial market. By the way, sometimes it's nice to drive a Maserati.
The 386BSD Project and Berkeley UNIX
The 386BSD project was established in the summer of 1989 for the specific purpose of porting the University of California's Berkeley Software Distribution (BSD) to the Intel 80386 microprocessor platform.
Encompassing over 150 Mbytes of operating systems, networking and applications software, BSD is a fully functional complete operating systems software distribution. The goal of this project was to make this cutting-edge research version of UNIX widely available to small research and commercial efforts on an inexpensive PC platform. By providing the base 386BSD port to Berkeley, our hope is to foster new interest in Berkeley UNIX technology and to speed its acceptance and use worldwide. We hope to see those interested in this technology build upon it in both commercial and noncommercial ventures.
In each of these articles we will examine the key aspects of software, strategy, and experience that make up a project of this magnitude. We intend to explore the process of the 386BSD port, while learning to effectively exploit features of the 386 architecture for use with an advanced operating system. We also intend to outline some of the trade-offs in implementation goals, which must be periodically re-examined. Finally, we will highlight extensions that remain for future work, perhaps to be done by some of you reading this article today.
Currently, 386BSD runs on 386 PC platforms and supports the following:
May 1991 - Porting Unix to the 386: THE INITIAL ROOT FILESYSTEM - Bill and Lynne describe the 386BSD root filesystem, a key component of kernel development.
April 1991 - Porting Unix to the 386: LANGUAGE TOOLS CROSS SUPPORT - Bill and Lynne describe "cross" mode operations as they work towards bootstrapping 386BSD.
March 1991 - Porting Unix to the 386: THE STANDALONE SYSTEM - Using their protected mode program loader, Bill and Lynne create a minimal 80386 protected mode standalone C programming environment for operating systems kernel development.
February 1991 - Porting Unix to the 386: THREE INITIAL PC UTILITIES - Utilities to let you execute GCC-compiled programs in protected mode from MS-DOS, and copy files to a shared portion of disk so MS-DOS and Unix can exchange information.
Copyright © 1991, Dr. Dobb's Journal