|Jolitz Heritage ]||
Then and Now
This was our first article on 386BSD, appearing at the end of 1990.As the article series attmped to duplicate the methodology of our project, this article coincides with theoriginal software specification that we wrote and had solicited on the INTERNET months prior to the start of system coding.
When originally written in September/October, the second version of 386BSD (based on 4.3 Reno) was settling down, and our attentions were turned towards organizing and communicating what we had experienced doing the port. Since our port was still dependant on licensed and effectively very private code, there was no presumption that the project could be stretched into a complete system, and we had planned simply to document the experience, our code, and arrange with the University of California an immediate release of the early system to other researchers.
Other versions of BSD-like systems for the 386 were known to be present at the time of this writing but unavailable for general research use. Worse yet, BSD itself was dependant on VAX's that even as we were writing this article were being decommissioned and sold for scrap. The main objective here was to "move the flag". We had been working with Berkeley on this project for over a year and a half at this time, playing a game of catch-up on subsequent BSD minor releases.
After the article was accepted for publication, a number of events occurred that were to shape the future. In November, Berkeley made the decision to go for a completely unencumbered system on a fast time table, ostensibly to be made available in the traditional BSD open fashion. This bold and agressive direction galvanized many in the community; it was seen as the fitting next step in research UNIX systems evolution, since by that time so much of the system was already novel and the remaining "unclean" portions dated and no longer appropriate. Since other UNIX-like systems had already been accomplished, it seemed like one with the BSD heiritage of innovative technology could galvanize the world at large. The laurels of accomplishing this feat were the rewards for a system anyone might use. Obviously, as chronicalled quite correctly at the time in Jon Erickson's editorial, this was "The Right Thing To Do".
In December, the software was officially donated to the University, and we returned to our normal activities, knowing 386BSD was finished and could be used by other University researchers.
At this point, the kernel was using the "old" Berkeley virtual memory system, as well as the traditional UNIX per-process data (u., or user structure). The system simulated the VAX's MMU by having linear user and kernel page tables, and context-switched the per-process information as a portion of the user process address space. Autoconfiguration, bootstrap, and disk layout was arranged like a VAX, perhaps to a too detrimental degree. In retrospect, the traditional UNIX arrogance ran quite deep. In stepping back from the port, the "VAXisms" were immediatly obvious as the central weakness of the work. In successive articles some of these dependancies were lost as the Networking Release version evolved (Recursive Pagemap )
The article series attempted to keep itself current to within about 3 months of the version of software in development,, which was no mean feat since the fundamental system, utilities, and compilers were under revision at the same time (typical university software development environment).
None of these legacies are present in the current release. Interestingly, many industry experts would frequently remark that the way one made for a efficient UNIX system was to "make it look like a VAX". The converse was found with 386BSD; modernizing the system so that it was no longer biased towards the VAX greatly improved performance on the 386; and should likewise extend to other modern archetectures (like PowerPC and Alpha).
--W.F.J., May 1994
Copyrightę1994 Willaim & Lynne Jolitz