1 2 3 4 5 6 7 8 TeleMuse 9 386BSD Project 10 Oakland, CA. 11 510-420-0174 12 13 September 1, 1994 14 15 16 Dear Colleague: 17 18 We are pleased to present the October 1994 386BSD 19 Release 1.0 update to our earlier 1992 386BSD Release 0.1. 20 This release is copyrighted by William F. Jolitz, TeleMuse, 21 but is made available for free redistribution. It requires 22 no prior license from AT&T or The Regents of the University 23 of California. However, individual packages and/or files in 24 the user portion of this release may contain additional 25 restrictions beyond that discussed in the file COPYRGHT.TXT. 26 In these cases, the source code copyright and/or license 27 agreement for that individual package and/or file should be 28 referred to for usage guidelines. 29 30 This new release of 386BSD contains portions of the 31 prior 386BSD release along with completely new material 32 written by the developer and not made available prior to 33 this release. It also contains updates and new work 34 previously made available to the Internet community compiled 35 and ready for use as a courtesy to the user. (Please refer 36 to the CONTRIB.TXT file for other contributors to the 37 development of 386BSD releases). 38 39 Although many portions of this work have been written 40 and incorporated only recently, and thus have not been well- 41 tested, we have received numerous requests for portions of 42 this system. Therefore, we are providing this release as an 43 experimental test release for interested developers. 44 45 The purpose of the remaining sections of this letter is 46 to familiarize the user with the new technical details of 47 this release so that it may be better understood prior to 48 use. 49 50 Distribution Contents 51 52 This distribution is a complete source and binary 53 distribution for the 80386, 80486, and Pentium family of 54 microprocessors running on a PC-AT platform 55 (ISA/EISA/PCI/VESA bus). A limited number of device drivers 56 is provided. However, the barrier to the addition of new 57 drivers has been significantly lowered with the changeover 58 to the new modular kernel arrangement in 386BSD (see the 59 Highlights section for more information). 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 This software distribution is being made available to 75 official Internet distribution mirror sites by UCSF from the 76 site bsdserver.ucsf.edu as a courtesy to the educational and 77 research community. Due to limitations in Internet 78 connectivity, only official Internet distribution sites may 79 mirror this software for redistribution to others. Contact 80 the system administrator for mirror site instructions. 81 82 This software distribution is also available on a 83 bootable CD-ROM as part of the 386BSD Release 1.0 Reference 84 CD-ROM from Dr. Dobbs Journal (Miller-Freeman Publishing). 85 This special CD-ROM also contains Windows-formatted and 86 hyperlinked 386BSD information including annotations of 87 select kernel files, articles, and other 386BSD-specific 88 information. The system can be booted and run from Windows 89 and/or installed in a partition on select PC configurations. 90 For further information contact: 91 92 386BSD Reference CD-ROM 93 411 Borel Avenue 94 San Mateo, CA. 94402 USA 95 1-800-872-7467 VOICE 96 1-415-358-9749 FAX 97 1-415-3580-9500 (outside of USA) 98 99 100 This distribution represents a work-in-progress. While 101 much information can be divined from the actual source code 102 contained with this distribution, the annotations and other 103 writings on the CD-ROM discuss this work in much greater 104 detail (along with items which have been developed but are 105 not yet ready for release). These writings are the primary 106 reference for past, current, and future 386BSD development 107 and should be referred to prior to embarking on any new 108 system development. It should be noted that these and other 109 writings on 386BSD are not considered part of the general 110 386BSD source/binary distribution and are made available 111 only through Miller-Freeman Publications. 112 113 Intended Audience for this Distribution 114 115 This release is intended for experienced system 116 developers and others who wish to preview or experiment with 117 the most recent 386BSD release. While theoretically 118 possible, due to the massive amount of change made 119 throughout the system to accommodate new kernel development 120 it is not recommended that new portions of this release be 121 incorporated into older versions of the system. This system 122 is also not intended to be used on production or commercial 123 systems. If a production or commercial system is required, 124 the developer recommends the purchase of a commercial grade 125 product for the PC from a major vendor such as SUN 126 Microsystems or Microsoft. 127 128 129 130 131 132 133 134 135 136 137 138 139 140 There is no support available for 386BSD Release 1.0 141 (see the file SOFTSUB.TXT for information on bugs fixes and 142 software submissions). It is instead recommended that users 143 inexperienced with 386BSD or those planning on attempting 144 any new kernel development first read the 386BSD 145 documentation available on the CD-ROM. For information on 146 how to learn about updates, fixes, new writings and talks 147 about 386BSD, please read the INFO.TXT file. 148 149 Summary of Changes from the Prior Release 150 151 This section outlines only the major changes to 386BSD 152 as discussed at the August 1994 SVNET Meeting in San Jose, 153 California (USA) by William F. Jolitz. As stated earlier, 154 the 386BSD CD-ROM annotations are intended as the primary 155 source for detailed discussions of implementation, design 156 considerations and trade-offs, and future considerations. 157 158 Major changes have been made to the 386BSD system. The 159 primary areas of change reside in the new modular kernel 160 arrangement, system configuration, and the virtual memory 161 system. 386BSD new work has been broken up into four areas: 162 extensibility, performance, restructuring for 163 multiprocessing, and usability issues. 164 165 Highlights of 386BSD Release 1.0 166 167 The kernel taxonomy (as outlined in man(9)) has been 168 completely changed, since the kernel is now composed of 169 independent modules. As a result of this, many new effects 170 are now possible: 171 172 * No more system configuration compilation files. 173 174 * Replacing compile-time metaphor with a run-time 175 metaphor. (However, still compile-time provisioning via 176 makefile). 177 178 * Controlled interface scope (module, class, kernel, 179 user). 180 181 * Module interfaces exportable to user mode or network. 182 183 A large number of changes have been made throughout the 184 kernel to remove bottlenecks to performance: 185 186 * Generic inlining (profiling, debugging, selective). 187 188 * Avoiding and/or reducing copyin/out costs. 189 190 * 2 KByte mbuf clusters (and improved ethernet driver). 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 * Reduced resource fragmentation (malloc, map entries). 207 208 * Extensively revised virtual memory system. 209 210 * Improved page reclamation and elimination of swapping. 211 212 * Reduced context switch and interrupt overhead and 213 process creation overhead. 214 215 Future work in 386BSD is oriented towards an exploration of 216 multiprocessing. As such, much preliminary work has been 217 done to facilitate multithreading in the kernel: 218 219 * Kernel thread generation (tfork(),texit()). 220 221 * Virtual address space sharing. 222 223 * Kernel stacks at unique kernel virtual addresses. 224 225 * Process relative operations (including copyin/out). 226 227 * Logical I/O mechanism. 228 229 * Thread creation independent of address space. 230 231 And finally, changes have been made to improve the usability 232 of the system: 233 234 * Dynamic configuration (symbolic, unordered, universal) 235 -- "plug-and-play". 236 237 * Uniform source tree and program build environments. 238 239 * Provision for multiple system environments. 240 241 * Provision for easy extensibility. 242 243 * Minimized system management overhead. 244 245 * Extended kernel tracing for performance evaluation and 246 fault isolation. 247 248 * Role based security to restrict/interdict intrusion.. 249 250 Whats New in the Design of 386BSD Release 1.0 251 252 Release 1.0 is the first official release of 386BSD. 253 Earlier work-in-progress versions of 386BSD had significant 254 problems that could not be addressed in a timely fashion 255 without redesign. Among the major changes in this release: 256 257 Virtual Memory System 258 The core of the virtual memory system was examined and 259 260 261 262 263 264 265 266 267 268 269 270 271 272 critically revised to eliminate problems exposed when 273 we attempted to unify the filesystem and virtual memory 274 system file state cache. It was also restructured to 275 eliminate the "glue" code used to attach it to the rest 276 of the kernel, and the kernel interface was expanded to 277 make more concise (as a part of the system's taxonomy) 278 the boundary with the kernel. Page reclamation was 279 greatly improved by a variable rate page scanner that 280 implements a form of LIFO on both referenced and 281 modified pages. 282 283 Configuration 284 Dynamic configuration of kernel drivers, line 285 disciplines, protocols and filesystems is present in 286 the kernel. Instead of a configuration program (e.g. 287 "config") that builds tables from system descriptions, 288 a single file is macro expanded by the "make" facility 289 to construct a kernel program, which may then be 290 tailored to a specific system by means of a file read 291 during system bootstrap (/.config). 292 293 Kernel Organization 294 While still compiled as a single file, the kernel is 295 arranged as a series of independent modules that 296 ultimately will be compiled and loaded independently 297 (see Research Directions following). The kernel is now 298 arranged quite differently, employing the modular 299 makefiles as used by the user utility programs. Thus, 300 independent makefiles for each subsystem are invoked by 301 a master makefile via composition. 302 303 Memory Allocation 304 Both the kernel's memory allocator (malloc), as well as 305 the virtual memory systems root memory allocator 306 (kmem_alloc) have been considerably reworked and 307 rewritten to reduce memory fragmentation and maintain 308 memory resource in a way that avoids many unnecessary 309 blocks for memory in the kernel. 310 311 Concurrent Objects 312 Processes now rely on kernel threads that may 313 eventually share a single address space. Kernel-only 314 threads share a single address space context on the 315 entire machine, so that context switches between them 316 can avoid high cost switches. Context switching between 317 ordinary processes is three to five times faster than 318 before, while signal delivery (real time from 319 generation to delivery) is now more than ten times 320 faster. 321 322 Interface Organization 323 Both kernel and user programs now operate under a 324 hierarchy of interface, where the only default set of 325 326 327 328 329 330 331 332 333 334 335 336 337 338 public interfaces correspond to industry standard ones 339 (e.g. POSIX 1003.1, as opposed to ad-hoc BSD or SVR 340 ones). This distinction is a means to starting a 341 process of separating out programs and interfaces in 342 such a way that multiple ad-hoc interfaces, or even 343 composite groups (like a particular combination of 344 groups) can be implemented on the system. A skeleton of 345 this structure be found in the "NONSTD" feature used in 346 the utilities, as implemented with libraries and 347 include files (for the moment only). The intent of this 348 work is to symbolically bind interfaces instead of 349 rooting new ones into the filesystem -- unfortunately, 350 since this is just the beginning of this process, it is 351 far from complete and has been left as an exercise for 352 the reader (only a "bsd" interface is present for use 353 in allowing "old" programs to function). 354 355 Security 356 The model of privilege and process credentials have 357 changed to allow for a more flexible treatment of 358 process privileges beyond the older single one 359 ("superuser") contained in the traditional UNIX model. 360 A new concept, that of a "role" under which the scope 361 of operations allowable to a process are classified, 362 has been added. Roles are independent of ordinary 363 POSIX attributes, and may in certain cases be entirely 364 determined within the kernel. 365 366 Detailed discussions of many of these areas, including 367 implementation, trade-offs and design goals, and future 368 directions are discussed in the annotations of select kernel 369 source code available from Miller-Freeman (see Distribution 370 Contents above). 371 372 Items Intentionally Not Included in Release 1.0 373 374 Certain works-in-progress, which are written but still 375 in the development and testing phase, were deemed too 376 premature to release and as such are not included in Release 377 1.0. The two primary items here are the dynamically boot- 378 loadable modules and the page cache (although certain parts 379 of both are evident in the changes in the kernel code itself 380 -- see the annotations for more information). We hope to 381 follow up Release 1.0 with these additional items as well as 382 other new work discussed in the following section. 383 384 In addition, no work from the incomplete 4.4 Lite was 385 include in this release, primarily because it has been made 386 available at the very close of this project. However, a 387 preliminary review of this work has already indicated that 388 some of the advantages hoped for from this work (such as in 389 the area of filesystems) appear ill-fitting to our current 390 technical directions (e.g. by relying more on compile time 391 392 393 394 395 396 397 398 399 400 401 402 403 404 binding), while others do not present a clear advantage 405 (e.g. leases) over the increase in complexity demanded for 406 proper implementation. At this point in time it is 407 difficult to assess what clear technical value can be 408 abstracted from the last University of California at 409 Berkeley BSD "release", since its incompleteness and lack of 410 new technical focus appears to limit it to the status of an 411 improved NET/2 release, and does not quite hold to the 412 standard of a traditional standard BSD release (a better 413 name for it might be "NET/3 - 1"). We do hope, however, that 414 after much review that we will be able to extract and 415 incorporate what technical value exists from this final BSD 416 release, if only to allow others the chance to pursue the 417 last remnants of this venerable and now ended tradition. 418 419 Research and Development Directions for the Next Release 420 421 While many in the BSD flock have concentrated on near- 422 term operations and support of BSD-based systems, our focus 423 of interest continues to be on the "hard" problems 424 afflicting both research (and commercial) systems 425 architectures today. As a brief status report and direction, 426 we include the following items which synopsize our projects 427 direction by selection of topics (again, many of the 428 implementation details are discussed in the annotations): 429 430 Configuration 431 We really need to finish what was started in Release 432 1.0 by breaking the remaining ties and allowing 433 independent compilation and run-time loading of 434 modules. In addition, the kernel is arranged to run in 435 "driver-less" mode via the BIOS/DOS drivers, allowing 436 post kernel load configuration by user process. This 437 configuration paradigm is extended to include revision 438 by a configuration daemon so that the kernel 439 capabilities can be altered to suit need. 440 441 Page Cache 442 Now that the virtual memory system has been stabilized, 443 the "glue" removed and some significant problems fixed, 444 all of the problem areas stressed by the page cache 445 have been eliminated. Thus, the page cache can now be 446 re-inserted into the system, entirely replacing the 447 pager, buffer cache, and significant portions of the 448 filesystem implementation. This change requires 449 considerable interface changes to the filesystem 450 interface and organization, as abstract state is cached 451 in a different way than that of the lower-level 452 transfer cache (the root problem is that of a level-of- 453 abstraction contradiction between the virtual memory 454 system and the filesystem). This change facilitates a 455 cache-consistent VM layer across a distributed system's 456 file-like objects (as is necessary for large processor 457 458 459 460 461 462 463 464 465 466 467 468 469 470 cluster use). 471 472 Multiprocessing 473 In Release 1.0 the kernel was restructured to allow for 474 certain kinds of multiprocessing to be implemented. 475 The thread mechanism must be completed to allow address 476 space sharing and remote context access via in-kernel 477 network proxies (not unlike NFS client sockets). In 478 this case, parallelism is present as shared or distinct 479 process context models, independent of actual processor 480 hardware (e.g. you can "cluster" on a SMP, or simulate 481 sharing by messaging across cluster processor 482 elements). Synchronization is to be achieved by a novel 483 scheme of binding threads to shared objects via a 484 static reservation arrangement, so that it is possible 485 to avoid embedding support for fine-grain locking 486 throughout the kernel program. It is anticipated that 487 while this solution will be less efficient than fine- 488 grain locking, it will be manageable for a project of 489 the scale of 386BSD and, if successful, afford the 490 opportunity to study ways of improving how to employ 491 parallelism in the operating system incrementally 492 across different degrees of coupling (e.g. intra- 493 processor, SMP, cluster, and so forth). 494 495 Security 496 Release 1.0 introduced the concept of a "role" and 497 embedded part of the implementation to show how it can 498 be employed. Unfortunately, both the filesystem 499 implementation (attribute/access mediation) and the 500 user level interface (chflags(), et al) are incomplete 501 to take advantage of this new mechanism. In addition, 502 the network protocols need to interact with the role 503 credential attribute to intrinsicly associate 504 communications content with it. Thus, part of this 505 concept is made impenetrable by inherent communications 506 properties, shifting the point of focus to the external 507 network. 508 509 SIGNA 510 Release 1.0 uses the old Berkeley protocol stack, which 511 works adequately for use with ethernet-based PC's. 512 However, the 386BSD Simple Internet Gigabit Networking 513 Architecture (SIGNA) must be combined with an adequate 514 hardware interface to exploit high-speed communications 515 (gigabit loopback interfaces serve no purpose) as well 516 as a robust kernel implementation. The jist of the 517 problem here is that a simple protocol implementation 518 merely passes the stress onto every other portion of 519 the kernel -- yet it is still necessary to support the 520 rich flexibility contained in the "old" implementation 521 as well. This gap between a proof of concept and a 522 viable replacement is admittedly large, but offers much 523 524 525 526 527 528 529 530 531 532 533 534 535 536 interesting new work to explore. 537 538 Dynamic Filesystem Binding/Stacking 539 Aside from the hype surrounding using compositions of 540 filesystems as a central operating system paradigm, the 541 convenience of decoupling the storage methods of a file 542 from the program-visible semantics of the filesystem 543 argues strongly for allowing filesystem stacking. 544 Existing systems that allow this do so in complex and 545 ad-hoc ways that seem to contain as many flaws as 546 virtues. Most rely on elaborate statically-bound 547 configuration arrangements that are actually more of a 548 way of converting filesystem objects as they pass 549 between layers than anything else. Perhaps more time is 550 spent in industriously maintaining filesystem 551 abstractions than achieving file I/O -- instead, we can 552 bind associated filesystem objects to the semantics 553 directly and have the effect of filesystem stacking 554 without the overhead (e.g. by lazy evaluation of 555 certain filesystem objects). This approach also lends 556 itself well to lowering the cost of maintaining cache- 557 consistency in distributed filesystems as well. In 558 short, we need a scalable filesystem interface instead 559 of the current VFS/VNODE arrangement. 560 561 Currents 562 In a similar vein, communications can be handled via 563 stackable protocols like streams through use of a 564 similar binding structure. By this choice, a streams- 565 like protocol stacking mechanism can be used that 566 similarly avoids the overhead of the rigid framework. 567 It appears that the frameworks for filesystem and 568 streams are strikingly similar, and it may be possible 569 to combine them (if not necessary to do so for certain 570 performance reasons). 571 572 Other Architectures: Power PC? 573 At some point a second architecture, preferably one in 574 wide use and with publically available details of 575 operation (unlike Pentium, for example), should be 576 chosen as a second designated 386BSD architecture. This 577 would allow us to avoid the temptation of exploiting a 578 specific processor too much. While this small project 579 cannot afford the disruption (and annoyances) of 580 supporting an arbitrary set of obscure (or obsolete) 581 architectures, supporting at least one other may be a 582 wise decision. The Power PC (and possibly Alpha) is a 583 potential candidate for this, among a few others. 584 585 UNICODE 586 The system needs to be extended to support 587 internationalization and localization using 16- and 32- 588 bit character sets, either by runic coding and/or full 589 590 591 592 593 594 595 596 597 598 599 600 601 602 wide character replacements. A POSIX w_termio module, 603 drivers, and a filesystem attribute to select wide- 604 character operation seem like the first step, followed 605 by the creation of a program development environment to 606 suit. 607 608 Emulation/Interoperation 609 The nascent support for multiple operating systems 610 personalities (NONSTDINC feature) along with user-mode 611 emulation capability need to be fully implemented to 612 allow support of arbitrary operating systems 613 applications program interfaces on a single operating 614 system kernel. It should be possible to compile and run 615 the same source without contextual change (as if a 616 different operating system was present). Both compile 617 time and run time capability are important here. 618 619 Error Recovery 620 Long a bane of UNIX systems in general, the entire 621 operating system's architecture and especially the 622 kernel program need to be restructured to eliminate the 623 "panic()" approach to system recovery. Instead, the 624 system needs to contain the damage, shed the affected 625 control path, release resources, and recover integrity. 626 In addition, the degree of integrity of all user- 627 visible objects must be tracked and bound with the 628 object. 629 630 Thank You 631 632 Thank You For Your Interest in the 386BSD Project. We 633 hope that this release encourages you towards positive and 634 productive operating systems research and development and 635 that your enthusiasm will allow us to release and document 636 even more exciting versions of 386BSD. 637 638 William F. Jolitz 639 Lynne Greer Jolitz 640 386BSD Project 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661