DOCSLIB.ORG

Dfly Usenix2005 Bof.Pdf

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Dfly Usenix2005 Bof.Pdf WWW.DRAGONFLYBSD.ORG Light Weight Kernel Threading and User Processes LWKT SUBSYSTEM USERLAND PROCESS SCHEDULER CPU #1 PROCESS RUNQ SCHEDULER BGL THREAD LWKT SCHEDULER BGL THREAD PROCESS1 (FIXED PRI) PROCESS2 THREAD PROCESS2 CURPROC ON CPU1 PROCESS3 CPU #2 BGL THREAD PROCESS4 LWKT PROCESS5 SCHEDULER THREAD PROCESS5 CURPROC ON CPU2 (FIXED PRI) BGL THREAD PROCESS6 IPI Messaging ●Abstraction promotes cpu isolative algorithms. ●IPI Messages avoid mutexes. Software crossbar approach. ●Critical sections to interlock against interrupts and IPIs. ●Many IPIs can be passive. Pipelining can be made optimal. CPU #1 CPU #2 SCHEDULER SCHEDULER ASYNC THREAD1 SCHEDULE IPI SCHEDULE THREAD2 THREAD2 MESSAGE THREAD2 ALLOCATOR ALLOCATE MEMORY THREAD1 ON CPU#1 ALLOCATOR THREAD2 ALLOCATOR PASSIVE FREE FREE IPI MEMORY MEMORY MESSAGE OWNED BY ON CPU #1 CPU #1 Light Weight Kernel Thread Messaging ●Amiga style message and port API. ●Highly Flexible. ●Semisynchronous: direct call to target's port agent. ●UP/SMP optimized ●Very fast synchronous path. THREAD #1 TARGET PORT (OWNED BY T2) PORT AGENT APP SEND MSG APP PROCESSES MSG SYNC RETURN THREAD #1 THREAD #2 TARGET PORT (OWNED BY T2) PORT AGENT SEND MSG (WAKEUP T2) GETMSG QUEUES MSG EASYNC APP APP REPLY PORT WAITMSG (WAKEUP T1) REPLY MSG RETURN Slab Allocator ●Per-CPU localization. ●Backed by kernel_map. ●No more kmem_map. CPU #1 CPU #2 THREAD THREAD THREAD THREAD THREAD THREAD REMOTE PER-CPU SLAB CACHE FREE PER-CPU SLAB CACHE (PASSIVE IPI) BULK BULK ●BULK=128K TYP BULK BULK ALLOCATION FREE ● ALLOCATION FREE (LOCK) (LOCK) HYSTERESIS W/FREE (LOCK) (LOCK) KERNEL_MAP Threaded Network Protocol Stacks ● NETISR TCP A Work being done by Jeffrey Hsu THREAD ● Utilizes LWKT messages and ports PCB PCB PCB ● 1 thread per cpu per protocol typ. NETISR TCP B ●UP is a degenerate case of SMP. THREAD PCB PCB PCB Etc PROTO NETIF SWITCH (IPI) NETISR UDP A THREAD PCB PCB PCB MB UF ALLOC PACKETS NETISR UDP B THREAD PCB PCB PCB Etc MBUF FREE USER READ (PASSIVE IPI) CPU #0 ●Mbuf free path expected to cross cpus. CPU #1 ●Cache and return, or cache and reuse? Threaded Network Protocol Stacks Wildcard PCBs for TCP ●Hash on (srcaddr, srcport, destaddr, destport). ●Replicate wildcard listen sockets. ●Create normal PCB on accept(). CPU #1 CPU #2 CPU #3 CPU #4 (TCP THREAD) (TCP THREAD) (TCP THREAD) (TCP THREAD) PCB 1 PCB 2 PCB 3 PCB 4 PCB 5 PCB 6 PCB 7 PCB 8 PCB 9 PCB 10 PCB 11 PCB 12 WILDCARD WILDCARD WILDCARD WILDCARD PCB #30 PCB #30 PCB #30 PCB #30 WILDCARD WILDCARD WILDCARD WILDCARD PCB #31 PCB #31 PCB #31 PCB #31 Threaded Network Protocol Stacks Wildcard PCBs PROGRAM CLOSE ●Reference counters require synchronization. MSG ●So don't use reference counters.. CPU #1 CPU #2 CPU #3 CPU #4 (TCP THREAD) (TCP THREAD) (TCP THREAD) (TCP THREAD) WILDCARD WILDCARD WILDCARD WILDCARD PCB #30 PCB #30 PCB #30 PCB #30 FREE PCB The Namecache FREEBSD DRAGONFLY optional, disconnected mandatory, connected namespace vnode locked namespace namecache locked Struct vnode Struct vnode LIST_HEAD(, ncp) v_cache_src; Struct ncp_list v_namecache; TAILQ_HEAD(, ncp) v_cache_dst; struct vnode *v_dd; Struct namecache (ncp) Struct namecache (ncp) LIST_ENTRY(ncp) nc_src; TAILQ_ENTRY(ncp) nc_entry; TAILQ_ENTRY(ncp) nc_dst; TAILQ_ENTRY(ncp) nc_vnode; struct vnode *nc_dvp; struct ncp_list nc_list; struct vnode *nc_vp; struct vnode *nc_vp; The Namecache ●Namespace locked by namecache, not by vnode. ●Negative namecache entries can be created and locked. ●Aliased vnodes do not confuse the kernel. VOP_RENAME *BSD: VOP_RENAME(dvp, fvp, fcnp, tdvp, tvp, tncp) DRAGONFLY: VOP_NRENAME(fncp, tncp) Struct filedesc struct vnode *fd_cdir; struct vnode *fd_rdir; struct vnode *fd_jdir; struct namecache *fd_ncdir; struct namecache *fd_nrdir; struct namecache *fd_njdir; The Namecache ●Simplified VFS interface: VOP_NRESOLVE(ncp, cred) ●Simplified kernel interface: nlookup(). ●No more namei(), no more lookup() ●No more componentnames, except in compatibility shims. ●Separate NLOOKUPDOTDOT for “..” lookups (ala Linux). ●Topological guarentees for referenced namecache records. ● Node remains intact in the topology even if file deleted. ● Traversal to root is guarenteed (getcwd, fstat, and more) ● Most dvp references replaced by ncp references. ●VFS involvement only for attribute access (for now). The Namecache Future work ●Intended to be hooked into a cache coherency layer (aliasing, SSI, NFS). ●Direct Attribute Caching. ●Good place for a MAC implementation. ●Clean up VFSs and remove shims supporting obsolete VOP's. Big Giant Lock Removal Matthew Dillon DragonFly BSD Project April 2005 Current BGL Coverage SERIAL FASTINT CLOCK INTERRUPT THREADS LWKT SOFTINT NETIF SUBSYSTEM THREADS -- IDLE (scheduler) DISK (messaging) THREAD THREADS TIMER (IN KERNEL) THREADS (IN USER) NETISR ROUTE TBL IPI MSGS SYSCALLS VFS =BGL NOT REQUIRED MEMORY SUB MEMORY SUB SLAB CACHE KMEM ALLOC =BGL REQUIRED Next Stage BGL Removal SERIAL FASTINT CLOCK INTERRUPT THREADS SOFTINT NETIF LWKT THREADS SUBSYSTEM IDLE DISK THREAD THREADS TIMER (IN KERNEL) THREADS (IN USER) NETISR ROUTE TBL IPI MSGS SYSCALLS VFS =BGL NOT REQUIRED MEMORY SUB MEMORY SUB SLAB CACHE KMEM ALLOC =BGL REQUIRED BGL Removal – Network Detail ●WORK BEING DONE BY JEFFREY HSU ●UTILIZES LWKT MSGS AND PORTS ●MULTIPLE THREADS PER PROTOCOL ●NO UNI-PROCESSOR PENALTY NETISR TCP A THREAD PCB PCB PCB NETISR TCP B THREAD PCB PCB PCB Etc PROTO NETIF SWITCH NETISR UDP A THREAD PCB PCB PCB PACKETS NETISR UDP B THREAD PCB PCB PCB Etc =BGL NOT REQUIRED The DragonFly BSD Project April 2005 Joe Angerson Galen Sampson David Xu YONETANI Tomokazu Matthew Dillon Hiroki Sato Craig Dooley Simon Schubert Liam J. Foy Joerg Sonnenberger Robert Garrett Justin Sherrill Jeffrey Hsu Scott Ullrich Douwe Kiela Jeroen Ruigrok van der Werven Sascha Wildner Todd Willey Emiel Kollof Kip Macy and Fred --> Andre Nathan Erik Nygaard Max Okumoto Hiten Pandya Chris Pressey David Rhodus WWW.DRAGONFLYBSD.ORG.
Load more

Recommended publications
  • Oracle Database Licensing Information, 11G Release 2 (11.2) E10594-26
    Oracle® Database Licensing Information 11g Release 2 (11.2) E10594-26 July 2012 Oracle Database Licensing Information, 11g Release 2 (11.2) E10594-26 Copyright © 2004, 2012, Oracle and/or its affiliates. All rights reserved. Contributor: Manmeet Ahluwalia, Penny Avril, Charlie Berger, Michelle Bird, Carolyn Bruse, Rich Buchheim, Sandra Cheevers, Leo Cloutier, Bud Endress, Prabhaker Gongloor, Kevin Jernigan, Anil Khilani, Mughees Minhas, Trish McGonigle, Dennis MacNeil, Paul Narth, Anu Natarajan, Paul Needham, Martin Pena, Jill Robinson, Mark Townsend This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.
    [Show full text]
  • The Design and Implementation of Multiprocessor Support for an Industrial Operating System Kernel
    Blekinge Institute of Technology Research Report 2005:06 The Design and Implementation of Multiprocessor Support for an Industrial Operating System Kernel Simon Kågström Håkan Grahn Lars Lundberg Department of Systems and Software School of Engineering Blekinge Institute of Technology The Design and Implementation of Multiprocessor Support for an Industrial Operating System Kernel Simon Kågström, Håkan Grahn, and Lars Lundberg Department of Systems and Software Engineering School of Engineering Blekinge Institute of Technology P.O. Box 520, SE-372 25 Ronneby, Sweden {ska, hgr, llu}@bth.se Abstract The ongoing transition from uniprocessor to multiprocessor computers requires support from the op- erating system kernel. Although many general-purpose multiprocessor operating systems exist, there is a large number of specialized operating systems which require porting in order to work on multipro- cessors. In this paper we describe the multiprocessor port of a cluster operating system kernel from a producer of industrial systems. Our initial implementation uses a giant locking scheme that serializes kernel execution. We also employed a method in which CPU-local variables are placed in a special sec- tion mapped to per-CPU physical memory pages. The giant lock and CPU-local section allowed us to implement an initial working version with only minor changes to the original code, although the giant lock and kernel-bound applications limit the performance of our multiprocessor port. Finally, we also discuss experiences from the implementation. 1 Introduction A current trend in the computer industry is the transition from uniprocessors to various kinds of multipro- cessors, also for desktop and embeddedsystems. Apart from traditional SMP systems, many manufacturers are now presenting chip multiprocessors or simultaneous multithreaded CPUs [9, 15, 16] which allow more efficient use of chip area.
    [Show full text]
  • The Dragonflybsd Operating System
    1 The DragonFlyBSD Operating System Jeffrey M. Hsu, Member, FreeBSD and DragonFlyBSD directories with slightly over 8 million lines of code, 2 million Abstract— The DragonFlyBSD operating system is a fork of of which are in the kernel. the highly successful FreeBSD operating system. Its goals are to The project has a number of resources available to the maintain the high quality and performance of the FreeBSD 4 public, including an on-line CVS repository with mirror sites, branch, while exploiting new concepts to further improve accessible through the web as well as the cvsup service, performance and stability. In this paper, we discuss the motivation for a new BSD operating system, new concepts being mailing list forums, and a bug submission system. explored in the BSD context, the software infrastructure put in place to explore these concepts, and their application to the III. MOTIVATION network subsystem in particular. A. Technical Goals Index Terms— Message passing, Multiprocessing, Network The DragonFlyBSD operating system has several long- operating systems, Protocols, System software. range technical goals that it hopes to accomplish within the next few years. The first goal is to add lightweight threads to the BSD kernel. These threads are lightweight in the sense I. INTRODUCTION that, while user processes have an associated thread and a HE DragonFlyBSD operating system is a fork of the process context, kernel processes are pure threads with no T highly successful FreeBSD operating system. Its goals are process context. The threading model makes several to maintain the high quality and performance of the FreeBSD guarantees with respect to scheduling to ensure high 4 branch, while exploring new concepts to further improve performance and simplify reasoning about concurrency.
    [Show full text]
  • BSD UNIX Toolbox 1000+ Commands for Freebsd, Openbsd
    76034ffirs.qxd:Toolbox 4/2/08 12:50 PM Page iii BSD UNIX® TOOLBOX 1000+ Commands for FreeBSD®, OpenBSD, and NetBSD®Power Users Christopher Negus François Caen 76034ffirs.qxd:Toolbox 4/2/08 12:50 PM Page ii 76034ffirs.qxd:Toolbox 4/2/08 12:50 PM Page i BSD UNIX® TOOLBOX 76034ffirs.qxd:Toolbox 4/2/08 12:50 PM Page ii 76034ffirs.qxd:Toolbox 4/2/08 12:50 PM Page iii BSD UNIX® TOOLBOX 1000+ Commands for FreeBSD®, OpenBSD, and NetBSD®Power Users Christopher Negus François Caen 76034ffirs.qxd:Toolbox 4/2/08 12:50 PM Page iv BSD UNIX® Toolbox: 1000+ Commands for FreeBSD®, OpenBSD, and NetBSD® Power Users Published by Wiley Publishing, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256 www.wiley.com Copyright © 2008 by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada ISBN: 978-0-470-37603-4 Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1 Library of Congress Cataloging-in-Publication Data is available from the publisher. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permis- sion should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4355, or online at http://www.wiley.com/go/permissions.
    [Show full text]
  • Filesystem Performance on Freebsd
    Filesystem Performance on FreeBSD Kris Kennaway [email protected] BSDCan 2006, Ottawa, May 12 Introduction ● Filesystem performance has many aspects ● No single metric for quantifying it ● I will focus on aspects that are relevant for my workloads (concurrent package building) ● The main relevant filesystem workloads seem to be – Concurrent tarball extraction – Recursive filesystem traversals ● Aim: determine relative performance of FreeBSD 4.x, 5.x and 6.x on these workloads – Overall performance and SMP scaling – Evaluate results of multi-year kernel locking strategy as it relates to these workloads Outline ● SMP architectural differences between 4/5/6.x ● Test methodology ● Hardware used ● Parallel tarball extraction test – Disk array and memory disk ● Scaling beyond 4 CPUs ● Recursive filesystem traversal test ● Conclusions & future work SMP Architectural Overview ● FreeBSD 4.x; rudimentary SMP support – Giant kernel lock restricts kernel access to one process at a time – SPL model; interrupts may still be processed in parallel ● FreeBSD 5.x; aim towards greater scalability – Giant-locked to begin with; then finer-grained locking pushdown ● FreeBSD 5.3; VM Giant-free ● FreeBSD 5.4; network stack Giant-free (mostly) ● Many other subsystems/drivers also locked – Interrupts as kernel threads; compete for common locks (if any) with everything else ● FreeBSD 6.x; – Consolidation; further pushdown; payoff! – VFS subsystem, UFS filesystem Giant-free FreeBSD versions ● FreeBSD 4.11-STABLE (11/2005) – Needed for amr driver fixes after 4.11-RELEASE ● FreeBSD 5.4-STABLE (11/05) – No patches needed ● FreeBSD 6.0-STABLE (11/05) – patches: ● Locking reworked in amr driver by Scott Long for better performance ● All relevant changes merged into FreeBSD 6.1 – A kernel panic was encountered at very high I/O loads ● Also fixed in 6.1 Test aims and Methodology ● Want to measure – overall performance difference between FreeBSD branches under varying (concurrent process I/O) loads – scaling to multiple CPUs ● Avoid saturating hardware resources (e.g.
    [Show full text]
  • Notice for Netapp HCI
    Notice About this document The following copyright statements and licenses apply to software components that are distributed with various versions of the NetApp HCI products. Your product does not necessarily use all the software components referred to below. Where required, source code is published at the following location: https://opensource.netapp.com/ 1 Notice Copyrights and licenses The following component(s) is(are) subject to the AESLib License (BSD 2.0 -) • AESLib License contribution to skein - Unspecified Copyright (c) 2003, Dr Brian Gladman, Worcester, UK. All rights reserved. AESLib License (BSD 2.0 -) Copyright (c) 2003, Copera, Inc., Mountain View, CA, USA. All rights reserved. LICENSE TERMS The free distribution and use of this software in both source and binary form is allowed (with or without changes) provided that: 1. distributions of this source code include the above copyright notice, this list of conditions and the following disclaimer; 2. distributions in binary form include the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other associated materials; 3. the copyright holder's name is not used to endorse products built using this software without specific written permission. DISCLAIMER This software is provided 'as is' with no explcit or implied warranties in respect of any properties, including, but not limited to, correctness and fitness for purpose. ------------------------------------------------------------------------- Issue Date: March 10, 2003 2 Notice The following component(s) is(are) subject to the Apache 1.1 • Apache Base64 functions - Unspecified Copyright (c) 1995-1999 The Apache Group. All rights reserved. Apache Software License Version 1.1 Copyright (c) 2000 The Apache Software Foundation.
    [Show full text]
  • Mandoc: Becoming the Main BSD Manual Toolbox
    mandoc: becoming the main BSD manual toolbox BSDCan 2015, June 13, Ottawa Ingo Schwarze <[email protected]> Cynthia Livingston’sOTTB “Bedifferent” (c) 2013 C. Livingston (with permission) > Ingo Schwarze: mandoc page 2: INTROI BSDCan 2015, June 13, Ottawa Brief history of UNIX documentation • The key point: All documentation in one place and one format. Easy to find, uniform and easy to read and write. Be correct, complete, concise. • 1964: RUNOFF/roffmarkup syntax by Jerome H. Saltzer,MIT. Unobtrusive,diff(1)-friendly,easy to hand-edit, simple tools, high quality output. • 1971: Basic manual structure by Ken Thompson and Dennis Ritchie for the AT&T Version 1 UNIX manuals, Bell Labs. • 1979: man(7) physical markup language for AT&T Version 7 UNIX. • 1989: mdoc(7) semantic markup by Cynthia Livingston for 4.3BSD-Reno. Powerful, self-contained, portable. • 1989: GNU troffbyJames Clarke. • 2001: mdoc(7) rewrite by Werner Lemberg and Ruslan Ermilovfor groff-1.17. • 2008: mandoc(1) started by Kristaps Dzonsons. • 2010: mandoc(1) is the only documentation formatter in the OpenBSD base system. • 2014: mandoc(1) used by default in OpenBSD, FreeBSD, NetBSD, illumos. 16:19:30 What is the mandoc toolbox? → < > Ingo Schwarze: mandoc page 3: INTROIIBSDCan 2015, June 13, Ottawa What is the mandoc toolbox? User perspective:man(1), the manual viewer One comprehensive tool! Normal operation always proceeds in three steps: 1. Find one or more manuals in the file system or using a database by manual name — man(1) — or by search query — apropos(1) =man -k The result of this step can be printed out with man -w.
    [Show full text]
  • USENIX October Proof 3
    FOR THE PAST COUPLE OF MONTHS, I have become absorbed in operating sys- RIK FARROW tems. My quest began with some consult- ing regarding security features of the cur- rent Linux kernel, including SELinux, then plunged even deeper during the HotOS workshop. I do not pretend to be a kernel hacker, but I am very interested in what musings goes on with the design and implementa- Rik Farrow provides UNIX and Internet security con- tion of operating system software. sulting and training. He is the author of UNIX System Security and System Administrator’s Guide to System V and editor of the SAGE Short Topics in System Like some others, I had wondered what had hap- Administration series. pened to FreeBSD 4’s stellar performance when Free- [email protected] BSD 5 appeared. Instead of getting faster, FreeBSD was slower. If I had bothered digging deeper, I would have learned that this was the result of far-reaching changes in the FreeBSD kernel. Michael W. Lucas ex- plains these changes in his article, which in turn is based on a talk given by Robert Watson about modify- ing the kernel to support SMP (symmetric multipro- cessing). And perhaps by the time you read this col- umn, FreeBSD 6 will have appeared, ready to utilize the new multiprocessor cores that are popping up. Lucas explains just why the transition from single- threaded to multi-threaded kernel takes so long and is so hard to do right. I first understood the importance of the Big Giant Lock when I was reviewing an early multiprocessing server that used SPARC processors.
    [Show full text]
  • Jordan Hubbard Apple Computer, Inc. Oh Really?
    *BSD is dying - Anonymous Coward, Slashdot ©1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004 Jordan Hubbard Apple Computer, Inc. Oh really? Let’s look at some stats... FreeBSD Users: 2.5 Million Server Installations (Netcraft) 2,500,000 1,875,000 1,250,000 625,000 0 1993 1997 2001 2003 2004 12 Mac OS X Users: 9 6 3 0 12 Million Jul '01 Oct '01 Jan '02 Apr '02 Jul '02 Oct '02 Jan '03 Apr '03 Jun '03 Oct '03 Oct '04 Applications: FreeBSD ports 12,000 9,000 6,000 10,796 9,662 3,000 6,077 2,723 1,161 0 209 1995 1997 1999 2001 2003 2004 Applications: 12,000 Mac OS X Native 12,000 9,000 6,000 3,000 0 Apr '01 Jul '01 Oct '01 Jan '02 Apr '02 Jul '02 Oct '02 Jan '03 Apr '03 Jun '03 Oct '03 Oct '04 Since the arrival of Mac OS X, BSD has become the biggest desktop UNIX variant on the planet. Yes, even bigger than Linux Take that, Anonymous Coward! Selective overview of Mac OS X Mac OS X Architecture Applications User Interface Application Frameworks Graphics and Media System Services OS Foundation Apple Confidential OS Foundation Usermode BSD Commands and Usermode User FileSystem Libraries Drivers Kernel BSD Kernel IOKit Driver FileSystem Network Families Process Management Drivers Mach Kernel VM Scheduling IPC Open Source “Darwin” base OS Foundation Usermode BSD Commands and Usermode User FileSystem Libraries Drivers Kernel BSD Kernel IOKit Driver FileSystem Network Families Process Management Drivers Mach Kernel VM Scheduling IPC BSD Kernel • FreeBSD 5.1 based (networking, vfs, filesystems, etc) • Unified Buffer Cache (different
    [Show full text]
  • BSD Projects IV – BSD Certification • Main Features • Community • Future Directions a (Very) Brief History of BSD
    BSD Overview Jim Brown May 24, 2012 BSD Overview - 5/24/2012 - Jim Brown, ISD BSD Overview I – A Brief History of BSD III – Cool Hot Stuff • ATT UCB Partnership • Batteries Included • ATT(USL) Lawsuit • ZFS , Hammer • BSD Family Tree • pf Firewall, pfSense • BSD License • Capsicum • Virtualization Topics • Jails, Xen, etc. • Desktop PC-BSD II – The Core BSD Projects IV – BSD Certification • Main Features • Community • Future Directions A (Very) Brief History of BSD 1971 – ATT cheaply licenses Unix source code to many organizations, including UCB as educational material 1975 – Ken Thompson takes a sabbatical from ATT, brings the latest Unix source on tape to UCB his alma mater to run on a PDP 11 which UCB provided. (Industry/academic partnerships were much more common back then.) Computer Science students (notably Bill Joy and Chuck Haley) at UCB begin to make numerous improvements to Unix and make them available on tape as the “Berkeley Software Distribution” - BSD A (Very) Brief History of BSD Some notable CSRG • 1980 – Computer Science Research Group members (CSRG) forms at UCB with DARPA funding to make many more improvements to Unix - job control, autoreboot, fast filesystem, gigabit address space, Lisp, IPC, sockets, TCP/IP stack + applications, r* utils, machine independence, rewriting almost all ATT code with UCB/CSRG code, including many ports • 1991 – The Networking Release 2 tape is released on the Internet via anon FTP. A 386 port quickly follows by Bill and Lynne Jolitz. The NetBSD group is formed- the first Open Source community entirely on the Internet • 1992 – A commercial version, BSDI (sold for $995, 1-800-ITS-UNIX) draws the ire of USL/ATT.
    [Show full text]
  • List of BSD Operating Systems
    FreeBSD-based SNo Name Description A lightweight operating system that aims to bring the flexibility and philosophy of Arch 1 ArchBSD Linux to BSD-based operating systems. 2 AskoziaPBX Discontinued 3 BSDBox 4 BSDeviant 5 BSDLive 6 Bzerk CD 7 DragonFly BSD Originally forked from FreeBSD 4.8, now developed in a different direction 8 ClosedBSD DesktopBSD is a discontinued desktop-oriented FreeBSD variant using K Desktop 9 DesktopBSD Environment 3.5. 10 EclipseBSD Formerly DamnSmallBSD; a small live FreeBSD environment geared toward developers and 11 Evoke system administrators. 12 FenestrOS BSD 13 FreeBSDLive FreeBSD 14 LiveCD 15 FreeNAS 16 FreeSBIE A "portable system administrator toolkit". It generally contains software for hardware tests, 17 Frenzy Live CD file system check, security check and network setup and analysis. Debian 18 GNU/kFreeBSD 19 Ging Gentoo/*BSD subproject to port Gentoo features such as Portage to the FreeBSD operating 20 Gentoo/FreeBSD system GhostBSD is a Unix-derivative, desktop-oriented operating system based on FreeBSD. It aims to be easy to install, ready-to-use and easy to use. Its goal is to combine the stability 21 GhostBSD and security of FreeBSD with pre-installed Gnome, Mate, Xfce, LXDE or Openbox graphical user interface. 22 GuLIC-BSD 23 HamFreeSBIE 24 HeX IronPort 25 security appliances AsyncOS 26 JunOS For Juniper routers A LiveCD or USB stick-based modular toolkit, including an anonymous surfing capability using Tor. The author also made NetBSD LiveUSB - MaheshaNetBSD, and DragonFlyBSD 27 MaheshaBSD LiveUSB - MaheshaDragonFlyBSD. A LiveCD can be made from all these USB distributions by running the /makeiso script in the root directory.
    [Show full text]
  • ZFS Boot Environments Reloaded NLUUG ZFS Boot Environments Reloaded
    ZFS Boot Environments Reloaded NLUUG ZFS Boot Environments Reloaded Sławomir Wojciech Wojtczak [email protected] vermaden.wordpress.com twitter.com/vermaden https://is.gd/BECTL ntro !"#$%##%#& ZFS Boot Environments Reloaded NLUUG What is ZFS Boot Environment? Its bootable clone%sna(shot of the working system. What it is' !"#$%##%#& ZFS Boot Environments Reloaded NLUUG What is ZFS Boot Environment? Its bootable clone%sna(shot of the working system. ● In ZFS terminology its clone of the snapshot. ZFS dataset → ZFS dataset@snapshot → ZFS clone (origin=dataset@snapshot) What it is' !"#$%##%#& ZFS Boot Environments Reloaded NLUUG What is ZFS Boot Environment? Its bootable clone%sna(shot of the working system. ● In ZFS terminology its clone of the snapshot. ZFS dataset → ZFS dataset@snapshot → ZFS clone (origin=dataset@snapshot) ● In ZFS (as everywhere) sna(shot is read onl). What it is' !"#$%##%#& ZFS Boot Environments Reloaded NLUUG What is ZFS Boot Environment? Its bootable clone%sna(shot of the working system. ● In ZFS terminology its clone of the snapshot. ZFS dataset → ZFS dataset@snapshot → ZFS clone (origin=dataset@snapshot) ● In ZFS (as everywhere) sna(shot is read onl). ● In ZFS clone can be mounted read write (and you can boot from it). What it is' !"#$%##%#& ZFS Boot Environments Reloaded NLUUG What is ZFS Boot Environment? Its bootable clone%sna(shot of the working system. ● In ZFS terminology its clone of the snapshot. ZFS dataset → ZFS dataset@snapshot → ZFS clone (origin=dataset@snapshot) ● In ZFS (as everywhere) sna(shot is read onl). ● In ZFS clone can be mounted read write (and you can boot from it).
    [Show full text]