development:The GCC Executable Format
Our kernel is a UNIX executable file, just like all of its applications. So what does the a.out file, compiled and loaded usiing GCC and utilities look like?The Purpose of Our PC Utilities
Why we wrote PC utilities to port UNIX with - the advantage of working from a primitive OS that runs on the absolute machine.Where We Go From Here
Ironically, these utilities advanced progress fast enough that once the kernel was operational, the biggest obstacle became booting off of DOS. So the next step was to implement a bootstrap and standalone system so that we could rid ourself of DOS entirely.Porting Unix to the 386: Designing the Software Specification
This, the first article, is the first published mention of 386BSD. By this time, the project had been operational for 18 months, and William Jolitz was at Berkeley working on the Net/2 release.
The 386BSD specification was in two parts - one that detailed getting to a operational system that could build itself and basic console applications, and a more extensive community involvement part, called "A Modest Proposal".The Definition of the 386BSD Specification
Choosing how far to go in supporting X86 architecture in order to get a basic BSD UNIX system to be able to bootstrap the futre efforts.386BSD Port Goals: A Practical Approach
We decided to shoot for a system that emphasized novel 386 support code to create a basic BSD environment on the 386. We assumed that by making it freely available, others will extend the work to remaining areas.Virtual Address Space Layout
386BSD executed programs with a virtual address similar to a VAX running UNIX. In February 1991, this changed so that the format of the process virtual address space memory usage could be arranged differently.Bootstrap Operation
How to bootstrap the system from hardware, loading the kernel program, itself a protected mode executable from secondary / nonvolatile / disk storage.Porting Unix to the 386: The Standalone System
This article, last of the original three done altogether in 1990, on getting the critical pieces functioning independantly that we needed to do the port. Once these we obtained, the kernel was inevitable.Watching for Land Mines
Anticipating problems allowed us to find flaws in our work. We use the standalone system for bootstrap to load test programs that work machine-dependant portions of the kernel.Where Do We Go From Here?
We had put the plan of the first article into action, used the second articles tools to load test programs as the kernel, extending standalone operation. This created a base for the kernel and user environment.Porting Unix to the 386: Language Tools Cross Support
We describe the need and use of a cross-support environment to create 386 code from a non-386 machine, so as to create the initial binarys before our port can generate them.386BSD Cross-Tools Goals
Our use of cross-tools was simply to bootstrap onto the 386 - not to perfect ongoing development. So, if we found a problem with the tool, we bypassed it with a one time workaround - cross tools didn't need to work for everything.What's in the Tool Chest?
The tool chest for 386BSD cross support included compiler, assembler, loader, libraries and include files. It did not include an emulation environment.Cross-Support Methodology
Our methodology was to prove that we could get a usable, tested executable across onto the native machine to be useful there. As we found and fixed, this methodology sped getting enough good and working native components, such that we could begin native development.Other Cross-Support Issues
We started with a cheap lunchbox PC with a 40MB drive, and had to change as we exhausted serial downloads and DOS was squeezed of the drive for space for BSD.Choosing a Sensible Cross-Host
Our Symmetric 375 was close but not identical to a 386 - its National 32000 series microprocessor was different. Yet it was a good choice for cross host in a cross development environment.Porting Unix to the 386: Copyrights, Copylefts, and Competitive Advantage
We describe the origin and orientation of the "Free Software" vs. "Open Software" efforts via respective licenses.Open Standards - Are they really "Open"?
Open standards, open source, and free software are not the same thing - they are very different.Copyright vs. Copyleft
The view of copyright and the GPL as it was back in the early 90's.Why Do We Need a Root Filesystem?
Whats different about operating systems like Unix that use a root filesystem, and other systems that don't require a filesystem to be mounted initially to operate?Porting Unix to the 386: Research and the Commercial Sector
Understanding the boundary between research and development with BSD, and where a balance between commercial efforts can be struck.