*BSD News Article 11573


Return to BSD News archive

Received: by minnie.vk1xwt.ampr.org with NNTP
	id AA1675 ; Tue, 23 Feb 93 14:53:02 EST
Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!sun-barr!news2me.EBay.Sun.COM!jethro.Corp.Sun.COM!lamer!lewy
From: lewy@sun.com (Lew Yobs)
Newsgroups: comp.os.386bsd.questions
Subject: Re: WFJ's talk last night...
Date: 19 Feb 1993 00:35:36 GMT
Organization: Sun Microsystems, Inc.
Lines: 120
Distribution: world
Message-ID: <1m1a0oINN8ds@jethro.Corp.Sun.COM>
References: <C2nHuD.5EC@raistlin.udev.cdc.com>
Reply-To: lewy@sun.com
NNTP-Posting-Host: lamer.corp.sun.com


Here's my notes on the talk at SVnet meeting last night. 
Notes are completely unofficial. flames > /dev/null

---------------------------------------------------------------------------
 
What: SVnet Meeting
Date: 93/02/17
Speaker: William Jolitz (BJ in this text)
 
Topics: 386BSD Present and Future, Law suit, etc.
 
1. Intro remarks
 
        Release 0.0 (92/03/17) was binary distribution
        Release 0.1 (92/??)    freely redistributable and modifiable
 
        Independent groups working on various extension efforts, e.g.
        - group in Russia working on 16-bit ISOcode port
        - group in former DDR working on ISOcode port too.
        - guy at novell also working along same lines
 
        WJ gets contributed s/w pieces from folks all around the world.
 
        Estimates > 30K machines are now running 386BSD.
 
        Widespread use as non-commercial system for academics and
        experimental development has developed as intended.
 
2. Futures
        386BSD has embedded in it some late 1960's concepts
           but now older machines are on the way out: mainframes, mini's.
 
        Emphasis on "going forward" for benefit of new research as main
           theme for 386BSD.
 
   A. Near term
        More stable; more extensible system.
           Too much is involved now with implementing changes in the unix
             system: kernel + libraries + allications must all be changed
             to accomidate / take advantage of changes to low levels.
 
         => Establish firm interfaces -- wait for 0.2 release!
 
   B Far term
        BJ will try to stay involved for 'the long term'
        focus on design for networking
 
Opens for questions:
 
Q. Request to elaborate on methods for localizing change side-effects.
A.  Began moving in this direction with 0.2 work:
    - Moving in the direction of C++.
    - classes idea for kernel objects
    - loadable drivers
    - subsystem encapsulation: drivers, filesystems, protocol code
    - autoconfiguring kernel
    - no cdevsw[]
    - code is not PIC (position independent code) yet so addresses get wired in
    - kernel is *much* smaller than in 0.1
    - BIG 0.2 items:
        rewritten VM system
        "__" files in kernel were bandaids and are being ripped out
        pagecache
        "clustering" - ability to load much buffer space at once
                        See usenix paper by Kleiman and McVoy
        vnode objects / vfs interactions cleaned up
                (More information discussed at meeting here I did not get.)
        stacking filesystems
                e.g. stack a compression filesystem with other fs type
                        to achieve "both"
    OVERLOAD INTERFACES are WJ's goal for system design
 
*** Somewhere during the meeting the topic moved to status of USL / UCB / BSDI
        lawsuit. No notes were taken by me on these discussions. See other
        postings in the newsgroup for claims / counter-claims, dirt, smut.
 
3. Release 0.2 status
        Is still not ready.
        - still are significant problems
        - much of kernel has been rewritten
                new vfs layer and fs code
        - idea of portals
                are files that are versioned with processes (??)
                new inode type
                new ipc type
        - need cheaper way of making network daemons for future network focus
        - ability to "export" user code to kernel
        - shared libraries
             is one of biggest current problem areas
             best of OSF and Sun: Doesn't know if can ship OSF loader
        - Los Alamos Nat'l Lab contributed code to allow kernel to operate
                at any location and with kernel size > 640KB
            Can he release this??
        - tcp/ip enhanced stack: triple 0.1 speed
        - snmp
        - bpf (berkeley packet filter)
        - tossed alot of interfaces; kernel much smaller
        - sockets now in vnode layer => is a loadable fs
        - can use up to 1GB of RAM
        - libraries have had their namespaces cleaned up; garbage names removed
        - any posix incompatibilities should be brought to BJ's atention
 
*** Only freely modifiable and redistributable code will be put into
        kernel and libraries.
 
 
Q: What is used for testing?
A: Has own test suites and group of early release testers.
 
*** Requests that all code submitters provide own test suite to verify code
        submitted.
 
---------------------------------------------------------------------------

---
______________________________________________________________________
Lew Yobs					Sun Microsystems
______________________________________________________________________