<!DOCTYPE HTML PUBLIC "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension//EN" [
<!ENTITY base CDATA "../..">
<!ENTITY date "$FreeBSD$">
<!ENTITY email 'hackers'>
<!ENTITY title "BSDCon 2002 FreeBSD Developer Summit">
<!ENTITY % navinclude.about "INCLUDE">
<!ENTITY % developers PUBLIC "-//FreeBSD//ENTITIES FreeBSD Developers Entities//EN"> %developers;
]>

<html>
&header;

<p>The second FreeBSD Developer Summit was held on February 15, 2002, at
  the Cathedral Hills Hotel in San Francisco, CA, immediately following
  the USENIX 2002 BSD Conference at the same location.  The FreeBSD
  Developer Summit was sponsored by DARPA and NAI Labs, and hosted by NAI
  Labs.  Notes were taken by George Neville-Neil and edited by Robert
  Watson.  Markup by Murray Stokely.</p>

<p>Meeting began at 09:30am, ended at 5:00pm.</p>

<h2>Agenda</h2>
<ul>
  <li><a href="#kobj">Inheritance added to Kobj</a></li>
  <li><a href="#arch">Architectures</a></li>
  <li><a href="#toolchain">Toolchain</a></li>
  <li><a href="#geom">GEOM framework</a></li>
  <li><a href="#network">Networking</a></li>
  <li><a href="#trustedbsd">TrustedBSD</a></li>
  <li>Lunch</li>
  <li><a href="#kse">KSE</a></li>
  <li><a href="#smpng">SMPng</a></li>
  <li>Devd/Devfsd</li>
  <li><a href="#releng">Release Engineering</a></li>
  <li><a href="#conclusion">Conclusion</a></li>
</ul>

<h2>Attending:</h2>

<p>In person:</p>

<ul>
  <li>John Baldwin</li>
  <li>Doug Barton</li>
  <li>Jake Burkholder</li>
  <li>David O'Brien</li>
  <li>Chad David</li>
  <li>Jason DiCioccio</li>
  <li>Matthew Dillon</li>
  <li>Julian Elischer</li>
  <li>Brian Feldman</li>
  <li>Justin Gibbs</li>
  <li>Jeffrey Hsu</li>
  <li>Poul-Henning Kamp</li>
  <li>Greg Lehey</li>
  <li>Jonathan Lemon</li>
  <li>Terry Lambert</li>
  <li>Scott Long</li>
  <li>Warner Losh</li>
  <li>Michael Lucas</li>
  <li>Eric Melville</li>
  <li>Kenneth Merry</li>
  <li>Jonathon Mini</li>
  <li>Mark Murray</li>
  <li>Alfred Perlstein</li>
  <li>Andrew Reiter</li>
  <li>Ken Merry</li>
  <li>Jeff Rhyason</li>
  <li>Paul Richards</li>
  <li>Benno Rice</li>
  <li>Luigi Rizzo</li>
  <li>Jeff Roberson</li>
  <li>Nick Sayer</li>
  <li>Gregory Shapiro</li>
  <li>Brian Somers</li>
  <li>Murray Stokely</li>
  <li>George Neville-Neil</li>
  <li>Chris Vance</li>
  <li>Jacques Vidrine</li>
  <li>Robert Watson</li>
  <li>Kelly Yancey</li>
  <li>Jennifer Yang</li>
</ul>

<p>On The Phone:</p>

<ul>
  <li>Chris Costello</li>
  <li>Brooks Davis</li>
  <li>Josef Karthauser</li>
  <li>Bosko Milekic</li>
  <li>Thomas Moestl</li>
</ul>

<p>Via webcast:</p>

<p>Joe Karthauser is recording the call and is web casting.</p>

<p>The meeting followed a format where each section was led by an
  individual and then a discussion ensued.  Not all of the discussion
  was caught but I have tried to make those sections understandable.</p>

<div class="topic">
<hr>
<h2>Opening Remarks - Robert Watson</h2>

<p>Welcome to the second FreeBSD Developer Summit at BSDCon 2002.
  This event is sponsored by:</p>

<ul>
  <li><span class="sponsor">Defense Advanced Research Projects Agency
    (DARPA)</span></li>
  <li><span class="sponsor">NAI Labs, the Security Research Division of
    Network Associates</span></li>
</ul>

<p>The sponsors covered the cost of the room, food, telephone access,
  etc.  In addition, Joe Karthauser is providing webcast access, and
  Yahoo! is providing bandwidth for that using the FreeBSD.org
  cluster.</p>

<p>This is actually the second FreeBSD Developer Summit -- the first
  was at the USENIX Annual Technical Conference in Boston last summer.</p>

<p>The goals are to provide the opportunity for insight into on-going
  work, and to solicit comments, design input, and help on parts of
  the work.</p>

<p>There are rules of engagement.  Presenters should attempt to
  remember to check for questions on the phone, respect people asking
  questions, keep moving, and if told to stop, stop, as well as
  provide notes on the presentations later.  Others should do the
  same, especially with regards to stopping when asked to stop.</p>

<p><em>(Tentative schedule reviewed)</em></p>

<p>People will be on their own for lunch.</p>

<p>Let's go around the room, please give your name, and say something
  about what you do or why you're here.</p>
</div>

<div class="topic">
<hr>
<a name="kobj"></a>
<h2>Inheritance Added to KOBJ - Justin Gibbs</h2>

<p>Inheritance models have been put into newbus to reduce code
  duplication.  This was done because he was trying to get cardbus to
  work.  Code did not adhere with the spec.  There were conflicts with
  copying from PCI.  Cardbus is just an extension to PCI.</p>

<p>If you look at the current cardbus under BSD it's just all of PCI
  with symbols renamed.  Newbus is an OO type framework was and was
  half way there.  KOBJ and Newbus work today with a table of methods.
  To invoke a method an indirection is done to a lookup.  This makes
  it so that the invoker doest not need to know where the invoked
  method is.</p>

<p>The extension that was added is that instead of a single table it's
  a list of interfaces.  Every interface can inherit from a parent.
  In cardbus there is a list.  One method is the device interface for
  probe/attach.  Then there is an interface for the bus.  The third is
  a sys parsing interface that can be shared with pccardd.</p>

<p>Inside this the interfaces inherit from PCI and then he
  overrides a few methods.</p>

<p>The amount of code to support cardbus drops from 1000s of
  lines to a few hundred.</p>

<p>The system is implemented through the indirection already in
  newbus.  When a class is registered the way you declare it is a list
  of interfaces.  Each interface can declare a parent.  The compiler
  walks the list to find the correct function.  This allows you to
  call your superclass.</p>

<p>The only thing that gets a little ugly is that some of the ways you
  specify your class or invoke a superclass.  You can generate a macro
  wrapper but you have to know which interface is yours.</p>

<p>Another upshot is that the way most drivers are implemented today
  if they need a generic method they have to explicitly put that into
  their method table.  If they don't need it then they don't.  With
  the inheritance model you just create a null interface.</p>

<p>Diffs on his web site.</p>

<p>Whole method tables collapse to one or two entries.</p>

<p>Open issues:</p>

<ul>
  <li><p><strong>Interface versioning.</strong> - What he's been
    looking at is to munge the interface name to deal with versions.
    It's hard to hide this and work with it.</p>

    <p>Linux does this by modifying the .o</p>
  </li>

  <li><p><strong>Multipathing</strong> - The reason for an interest in
    multi-pathing is that systems today already have to do this,
    i.e. SCSI systems.  Many NUMA systems have CPUs with private I/O
    to a SAN.  When you do I/O you use the local device. This
    introduces locking issues for access.</p>

  <p>Another case is that there can be more than one way to enumerate
    a device in the system.  I.e. PCI vs. ACPI</p>

  <p>The basic idea that he has requires a different invocation method
    in newbus.  If you have to go up your bus chain there is a
    problem.  What he proposes is to pass a path object and a cursor
    that points to where you are in the path.  Then anyone along the
    path can see above or below etc.  A path is an array of deviceD
    pointers and a cursor is a deviceC.</p>

  <p>To implement this you have to modify all of these interfaces.
    This is very mechanical.  He's got ACPI, SIO, ATA, WaveLAN working
    now.  Each of these drivers takes about 5 minutes.  If you care to
    take more thought then you can collapse the drivers.  The
    simplification he has now only covers certain parts of cardbus or
    pccard.</p>
  </li>
</ul>

<p>His question is what release should this go into and how do we
  manage the transition if we decide to do this?</p>

<p>How do we design the versioning?  Run time?  Link time?  In the
  multipathing case is an array of dev_t sufficient?</p>

<h3>Discussion</h3>

<div class="discussion">

<p><strong class="speaker">Anon</strong> : I hesitate to throw this
  out.  The way you do version verification in Solaris is that an init
  gets called which passes a version to the api to check it.  Another
  thing you get from init.</p>

<p>In the Solaris case there is a single number.  How do I automate
  that versioning check with more interfaces?</p>

<p><strong class="speaker">Paul</strong> : I don't think we should
  over engineer the problem.  We only bump per release in libraries.</p>

<p><strong class="speaker">Justin</strong> : When you bump the version
  is one part of it.</p>

<p><strong class="speaker">Julian</strong> : Do you want more than one
  version at once?</p>

<p><strong class="speaker">Justin</strong> : Assuming we use name
  munging you could have.</p>

<p><strong class="speaker">Gnn</strong> : Have you looked at COM?</p>
  
<p><strong class="speaker">Warner</strong> : I have a few comments.
  There are several problems in one here.  I like the multiple
  inheritance.  The versioning seems orthogonal.  The multipath is
  orthogonal.  We should break this apart.</p>

<p><strong class="speaker">Justin</strong> : I have 14K lines of diffs
  just to make multiple-inheritance work on my laptop.</p>

<p><strong class="speaker">Julian</strong> : The other drivers will
  still work.</p>

<p><strong class="speaker">Justin</strong> : No they will not, they'll
  die early in init.  I could turn those into fatal errors.</p>

<p><strong class="speaker">PoulHK</strong> : If the change is so
  significant then the first thing we want to do is versioning.</p>

<p><strong class="speaker">Justin</strong> : Its almost as if you want
  a version of newbus.</p>

<p><strong class="speaker">PoulHK</strong> : A change of this scale is
  not very easy to get all right.  Particular because we can't change
  all drivers.</p>

<p><strong class="speaker">Justin</strong> : The only saving grace is
  that the transition can be mechanical.</p>

<p><strong class="speaker">PoulHK</strong> : Why not a compatibility
  layer while doing conversion?</p>

<p><strong class="speaker">Justin</strong> : Sure and then you could
  use Perl to change the whole tree.  I hesitate because in 90% of my
  own changes led to code reduction and we should do that.</p>

<p><strong class="speaker">PoulHK</strong> : I think we'll have the
  human eyes.</p>

<p><strong class="speaker">David O</strong> : How long to get your
  basic framework working?</p>

<p><strong class="speaker">Justin</strong> : Right now my stuff is
  done, the rest of the tree is a man/week.  I'd like to get
  versioning done now.</p>

<p><strong class="speaker">Mark M</strong> : Does that include the
  script?</p>

<p><strong class="speaker">Justin</strong> : No manually.</p>
  
<p><strong class="speaker">Julian</strong> : The problem is the
  requirement where you can't break things.  Perhaps we should have
  official breakage.  For instance for a week.</p>

<p><strong class="speaker">Nick</strong> : If you're going to do that
  then lay down a tag before the breakage.</p>

<p><strong class="speaker">PoulHK</strong> : Development model
  discussion.  Lets limit this discussion.</p>

<p><strong class="speaker">Robert</strong> : Lets assume the
  discussion of how it gets into the tree is not relevant.  Do you
  want the versioning before then?</p>

<p><strong class="speaker">PoulHK</strong> : Two questions we should
  figure out first.  1) Any objections?</p>

<p><strong class="speaker">Warner</strong> : One last point.  It seems
  like we're spending a lot of effort re-inventing the object wheel.
  We should just shoot KOBJ and consider using a subset of C++ to do
  this.  Then we can leverage the language.</p>

<p><strong class="speaker">Justin</strong> : One problem is that C++
  does not allow this easily.  If you do eC++ then there is
  multiple-inheritance.</p>

<p><strong class="speaker">Warner</strong> : I mean C++ with no
  exceptions but not eC++.</p>

<p><strong class="speaker">Justin</strong> : Then people say they want
  exceptions.</p>

<p><strong class="speaker">Julian</strong> : I wouldn't mind having
  our own pre-processors.</p>

<p><strong class="speaker">Robert</strong> : Let's move on.</p>
  
<p><strong class="speaker">Nectar</strong> : COM does work its in
  Mozilla we can use this kind of technology.  We don't need C++ to do
  those things.</p>

<p><strong class="speaker">Justin</strong> : One last thing is the
  problem in this inheritance model is how you deal with IVARS.  The
  problem is that those name spaces are not unique.  What I'm thinking
  of doing is passing the interface object along.  This gives you a
  further</p>

<p><strong class="speaker">Brian</strong> : C++ won't help us solve
  versioning.  Although COM would solve some of these problems it
  should not be in the fast path.</p>

<p><strong class="speaker">Robert</strong> : Lets not go there.</p>
  
<p><strong class="speaker">Warner</strong> : The other issue is the
  softc issue.  Only one can own it.</p>

<p><strong class="speaker">Justin</strong> : You can use ivars for
  that.</p>

<p><strong class="speaker">Warner</strong> : There are issues with
  bridges.</p>

<p><strong class="speaker">Justin</strong> : You use a method to get
  to your ivars which hang off of the softc.</p>

<p><strong class="speaker">PoulHK</strong> : Half of us have no idea
  because we have no docs.</p>

<p><strong class="speaker">Robert</strong> : Lets go to the phone.</p>
  
<p><strong class="speaker">Robert</strong> : No technical questions on
  the phone.</p>
</div>
</div>

<div class="topic">
<hr>
<a name="arch"></a>
<h2>New Architectures</h2>

<h3>PowerPC - Benno Rice</h3>

<p>Has now committed the page map code with something more sane.  Has
  also got the system to the point where it tries to mount root.
  Turning on invariants blows it up.  Hoping to get to single user in
  a month or so on the simulator.  With some luck we may get to
  multi-user by 5.0.  Needs some more help.  Possibly on real
  hardware.  That's about it.</p>

<h4>Discussion:</h4>

<div class="discussion">
<p><strong class="speaker">Robert</strong> : This relates to release
  engineering later.</p>

<p><strong class="speaker">David</strong> : Is everything in CVS?</p>
  
<p><strong class="speaker">Benno</strong> : Not everything yet, but
  things have to be cleaned up.  Some time in the next week after the
  invariants problem is fixed.</p>

<p><strong class="speaker">PoulHK</strong> : What hardware?</p>
  
<p><strong class="speaker">Benno</strong> : Right now on pSim which is
  in ports.  Once that's working the first hardware will be new world
  apple hardware.  Some old world apple hardware and then a Motorola
  board.</p>

<p><strong class="speaker">Justin</strong> : What are the prospects
  for using this in embedded?</p>

<p><strong class="speaker">Benno</strong> : Depends on whether you've
  got open firmware or not.</p>

<p><strong class="speaker">David</strong> : Targeting embedded is
  very difficult.  Pick a reference platform then move on.  Wind River
  has 20+ boards etc.</p>

<p><strong class="speaker">Benno</strong> : What I'm hoping to do is
  to make this as easy as possible.</p>

<p><strong class="speaker">David</strong> : Given a reference platform
  its easier to build from there.</p>

<p><strong class="speaker">Benno</strong> : The other note that I will
  make is that I'm only targeting PowerPC similar to 700.</p>

<p><strong class="speaker">Warner</strong> : I was going to comment
  that NetBSD has done well with little tiny ports to different
  boards.</p>

<p><strong class="speaker">Justin</strong> : How different are these?</p>
  
<p><strong class="speaker">Gnn</strong> : Very different.</p>
  
<p><strong class="speaker">Anon</strong> : Have you had any help from
  Apple or hardware vendors?</p>

<p><strong class="speaker">Benno</strong> : I have a bit of help from
  them.  In terms of hardware support I've had none except for the
  Motorola board.</p>

</div>

<h3>IA64 - David O'Brien</h3>

<p>Kind of hosed now due to toolchain issues.  It will take
  significant effort to bootstrap this.  It may take a month to get to
  multi-user.</p>

<p>When Peter arrives later, he may have more to add.</p>

<h3>x86-64 - David O'Brien</h3>

<p>We have a toolchain that works and is mostly in the tree.  There is
  a simulator issue.  I need a new simulator from AMD but they're not
  responsive.  Hardware not available yet but we're not in a rush.</p>

<h4>Questions</h4>

<div class="discussion">
<p><strong class="speaker">Justin</strong> : During the NetBSD there
  was some talk about PAE coming for free.  Is that true and will it
  affect us?</p>

<p><strong class="speaker">David</strong> : Peter is already adding
  this stuff.</p>

<p><strong class="speaker">Justin</strong> : Peter is looking at the
  stuff that was presented here.</p>

<p><strong class="speaker">Warner</strong> : Isn't part of this
  meaning that ethernet drivers have to use DMA.</p>

<p><strong class="speaker">Justin</strong> : It's not as bad as it
  looks because all the devices don't need bounce buffers.</p>
</div>

<h3>Sparc64 - Jake Burk Burkholder</h3>

<p>Basic status is we boot multi-user on real hardware.  Looking at
  targeting Ultra 2, 5, 10 and Blade 100.  Something for 5.0 but it
  may be a very manual install procedure.  Toolchain is native but we
  haven't tested it much.  It is a hosted tool chain.  Runs on
  Sparc64, generates Sparc64 binaries, but it's not the full usual
  thing.  gcc3.1 and binutils 2.12</p>

<h4>Discussion</h4>

<div class="discussion">
<p><strong class="speaker">Anon</strong> : What is the
  bootstrapping?</p>
  
<p><strong class="speaker">Jake</strong> : TFTP.</p>
  
<p><strong class="speaker">Robert</strong> : Bootloader?</p>
  
<p><strong class="speaker">Jake</strong> : We can mount Solaris
  disks.</p>

<p><strong class="speaker">Robert</strong> : How likely that all of
  world will be self hosting by 5.0?</p>

<p><strong class="speaker">Jake</strong> : Right now we're having
  problems with Perl.</p>

<p><strong class="speaker">David</strong> : There is polishing to be
  done but even if you're not a hacker it's fine.</p>

<p><strong class="speaker">Jake</strong> : Still finding endianness
  problems.</p>

<p><strong class="speaker">Terry</strong> : If someone wanted to use
  that for 32 bit how tough would it be?</p>

<p><strong class="speaker">Jake</strong> : You'd need to rewrite the
  kernel.</p>

<p><strong class="speaker">Terry</strong> : Do you document that?</p>
  
<p><strong class="speaker">Jake</strong> : It's mostly pmap.</p>
  
<p><strong class="speaker">Anon</strong> : SBUS support?</p>
  
<p><strong class="speaker">Jake</strong> : Ultra 2 has sbus support.</p>

<p><strong class="speaker">Benno</strong> : Have you got the gem
  ethernet driver working?</p>

<p><strong class="speaker">Jake</strong> : Yes.</p>
  
<p><strong class="speaker">Robert</strong> : Any questions on the
  phone?</p>
</div>

<h3>StrongArm</h3>

<div class="discussion">
<p><strong class="speaker">Robert</strong> : We did have a slot for
  ARM related ports.</p>

<p><strong class="speaker">David</strong> : On StrongARM we can get to
  copyright messages etc.  This is a bunch of code off to the side.
  What path do we want to take on this?  Wait until it works?  Check
  it in now?</p>

<p><strong class="speaker">Justin</strong> : Who has been working on
  this?</p>

<p><strong class="speaker">David</strong> : Someone in Canada.</p>
  
<p><strong class="speaker">Robert</strong> : Is the person who's doing
  this work willing to go all the way to maintain it etc.</p>

<p><strong class="speaker">David</strong> : The basic idea is the
  iPAQ.  The idea is more of a reference port.</p>

<p><strong class="speaker">Warner</strong> : MIPS port is unchanged.
  Some people have this and are just deciding whether to contribute
  it.  Chicken and an egg problem.</p>

<p><strong class="speaker">Justin</strong> : Interesting embedded
  platform.</p>

<p><strong class="speaker">David</strong> : If it's on a DECStation
  then it's not embedded.</p>

<p><strong class="speaker">Warner</strong> : This is on current MIPS
  technology for a router company.</p>
</div>
</div>

<div class="topic">
<hr>
<a name="toolchain"></a>
<h2>Toolchain - David O'Brien</h2>

<h3>Questions:</h3>

<div class="discussion">
<p><strong class="speaker">John</strong> : What are the plans 5.0?</p>
  
<p><strong class="speaker">David</strong> : Interest is in new ports.
  For instance C++ will lag.  Like you say we need gcc3.1 and
  binutils.  Will commit to get kernel and interesting parts of user
  land working.  Very soon there will be something that those who want
  to play with it can download.  It's debatable who will clean this up
  for new hardware.</p>

<p><strong class="speaker">Robert</strong> : We'll discuss the release
  engineering later.  There is a notion of supported vs. non-supported
  and toolchains will have to follow.</p>

<p><strong class="speaker">Julian</strong> : There are some thread
  fixes that went in.  Patches to gdb?</p>

<p><strong class="speaker">David</strong> : I'm trying to get them out
  of someone.  If I get a patch I'll put it in.  I need paperwork from
  the FSF to commit it.</p>

<p><strong class="speaker">Julian</strong> : I'm going to need help to
  beat up gdb for KSE.</p>

<p><strong class="speaker">David</strong> : Talk to John, DFR and
  yourself on this.</p>

<p><strong class="speaker">Nick</strong> : How much change goes in to
  gcc for a FreeBSD release?</p>

<p><strong class="speaker">David</strong> : The issue is the dual
  a.out/elf stuff, that's the problem.</p>
</div>
</div>

<div class="topic">
<hr>
<h2>Architectural Issues (General Discussions)</h2>

<div class="discussion">
<p><strong class="speaker">PoulHK</strong> : I have 3 issues.  One is
  endianess in the on disk filesystem.  Do we want to be able to move
  a disk from Sparc64 to x86.  I also need to collect the various disk
  label formats.  What do we do about "you broke world on foobar
  architecture" issue?</p>

<p><strong class="speaker">Warner</strong> : I'll address the last
  question first.  We need to build up a set of machines or build up
  cross building.</p>

<p><strong class="speaker">David</strong> : I don't know if anyone set
  up an environment.</p>

<p><strong class="speaker">Warner</strong> : NetBSD has done some
  things to deal with this.</p>

<p><strong class="speaker">Robert</strong> : Supported release?  The
  	same thing can be done in the cross platform build.  If a
  	particular arch is going to be supported then we must have a
  	build cluster.

<p><strong class="speaker">Benno</strong> : On the subject of PPC I'd
  be willing to offer them.

<p><strong class="speaker">Nik C</strong> : The NetBSD folks are
  	talking about having a tinderbox environment.  We might talk
  	to them about sharing.

<p><strong class="speaker">PoulHK</strong> : On the subject of
  tinderbox.  About 2 years ago I set up a machine to test this kind
  of thing but got a lot of negative feedback.  If we want to do a
  tinderbox like system it will require buy in by the committers.</p>

<p><strong class="speaker">Nik C</strong> : I think the Mozilla team
  do it more with a web page status.</p>

<p><strong class="speaker">David</strong> : The gcc group does a
  tinderbox and it knows who did the commit.</p>

<p><strong class="action">Action item</strong> : This could be farmed
  out to sysadmins who want to contribute.</p>

<p><strong class="speaker">Justin</strong> : From my standpoint, if I
  could cross build the Sparc64 that would help.</p>

<p><strong class="speaker">Robert</strong> : If we're going to commit
  to having multiple platforms we need to solve this.</p>

<p><strong class="speaker">Nik C</strong> : There are also issues of
  regression testing.</p>

<p><strong class="speaker">David</strong> : I don't know what could be
  done with it.</p>

<p><strong class="speaker">PoulHK</strong> : This is a purely
  organizational question.  What does it take to do this.  Do we
  discuss this on developer?</p>

<p><strong class="speaker">Greg</strong> : I really do think we should
  try to find a way to be endian clean.</p>

<p><strong class="speaker">PoulHK</strong> : We're not going to take
  suggestions.  There will be a UFS2 and it will be 64bit.  As part of
  that we're still not sure if we will have to fork the UFS tree.  One
  of the things I was considering doing was at a slight performance
  hit doing big or little endianness on any disk.  Is that the way to
  do it?</p>

<p><strong class="speaker">Alfred</strong> : NetBSD has this and it's
  fast.</p>

<p><strong class="speaker">Justin</strong> : I would think of it terms
  of having two modules, one for each endian.</p>

<p><strong class="speaker">Benno</strong> : It would be nice to be
  able to do this when bringing up new big endian systems.</p>

<p><strong class="speaker">PoulHK</strong> : The performance is an
  issue but not as big as the code intrusion.  Should we do it as two
  separate filesystems or should we put this functionality directly
  into UFS2?</p>

<p><strong class="speaker">Matt</strong> : Two comments on the FS
  stuff.  One just from the point of view of fixing bugs, I would
  prefer a single copy.  You could also do this via a conversion
  program.</p>

<p><strong class="speaker">PoulHK</strong> : It's not just a question
  about sticking in macros.  Soft updates makes this much more
  complex.</p>

<p><strong class="speaker">Jake</strong> : On big endian machines I
  just use NFS.</p>

<p><strong class="speaker">Greg</strong> : Conversion does not make
  any sense.</p>

<p><strong class="speaker">Justin</strong> : The other thing I want to
  say is that you can just have two modules.</p>

<p><strong class="speaker">Robert</strong> : Before we go too much
  further we should look at NetBSD.</p>

<p><strong class="speaker">PoulHK</strong> : Is there interest?</p>
  
<p><strong class="speaker">Gnn</strong> : Removable media is reason
  enough to do it.</p>

<p><strong class="speaker">Warner</strong> : When I've talked to
  NetBSD about this they consider it a feature they don't want to give
  up.</p>

<p><strong class="speaker">Robert</strong> : Any questions on the
  phone for architectures.</p>

<p><em>None.</em></p>
</div>
</div>

<div class="topic">
<hr>
<a name="geom"></a>
<h2>GEOM - Poul-Henning Kamp</h2>

<p>This changes the semantics of how we handle disks.  There also may
  be a slight performance hit.</p>

<p>The way it works is that there are methods that do transformation
  on the data on the disk.  Simple translations move data, complex
  transformations include encryption.</p>

<p>A method exposes one or more logical providers.  It exposes an
  interface where you can read/write a given size.</p>

<p>Other methods connect to the providers (consumers).  All providers
  have a dev method which allows it to show up in devfs.  There is a
  locking mechanism so you don't get parallel write problems.</p>

<p>The system is autoconfiguring.</p>

<p>The locking method.  When you open a device somewhere there are
  three counters associated with it, read, write, and exclusive.
  Exclusive bit prevents anyone else from opening it for write.</p>

<p>The intent is that the modules that recognize the on disk format
  will be endianness aware.  We hope that types will be explicit.  I
  need support from people to collect information on disk label
  formats.</p>

<p>Some current drivers do RAID etc. but I'd like to get that out of
  the drivers, again this requires information about the on disk
  format.  This would allow us to come up single user with a mirrored
  root.</p>

<p>I'd like input on :</p>

<p>I/O Statistics  (What to collect?)</p>

<div class="discussion">
<p><strong class="speaker">Greg</strong> : Read/Writes/Data transfered
  etc.  A way of finding the % busy time of each device.</p>

<p><strong class="speaker">PoulHK</strong> : With tagged queuing that
  is kind of useless.</p>

<p><strong class="speaker">Anon</strong> : The dev stack does keep
  track of how long a device has been busy (transaction outstanding).</p>

<p><strong class="speaker">PoulHK</strong> : One of the things there
  is an explicit cloning of the struct bio.  So you have one for each
  edge in the graph.  One of the things I want to be able to do is put
  in a transparent node.  This allows the moving of filesystems.</p>

<p><strong class="speaker">Anon</strong> : You have to have per
  transaction storage for this to work.</p>

<p><strong class="speaker">Justin</strong> : You want to have
  something to make it so that softupdates does not need to do the
  sleep/nice trick.</p>

<p><strong class="speaker">Matt</strong> : The real problem with fsck
  is that when you're skipping around the disk the 3ms seek can hurt
  other things.</p>

<p><strong class="speaker">Justin</strong> : You were saying that if I
  open ad0s1 read only then ad0 inherits that.</p>

<p><strong class="speaker">PoulHK</strong> : It depends on where you
  are in the tree etc.</p>

<p><strong class="speaker">Nick C</strong> : From the work you've done
  so far, do you have performance numbers?</p>

<p><strong class="speaker">PoulHK</strong> : No, because I'm in the
  simulator.  It does cost copying two struct bios.</p>

<p><strong class="speaker">Alfred</strong> : To modify the on disk
  disk label when its mounted read only can you modify it?</p>

<p><strong class="speaker">PoulHK</strong> : The BSD module decides
  that.  You cannot go down to the raw disk and do that.</p>

<p><strong class="speaker">Alfred</strong> : What if I want to expand
  the root filesystem?</p>

<p><strong class="speaker">PoulHK</strong> : Making a partition larger
  while its open is fine, making it smaller will be problematic.</p>

<p><strong class="speaker">Alfred</strong> : I think this locking is a
  bad idea.</p>

<p><strong class="speaker">PoulHK</strong> : The only thing that's
  going to be magic is having the root partition in single user.  I'm
  not going make an escape hatch for this.</p>

<p><strong class="speaker">Robert</strong> : Are there any other
  issues?</p>

<p><strong class="speaker">Justin</strong> : What is the name space?</p>
  
<p><strong class="speaker">PoulHK</strong> : The control will be
  sysctl.  I want to remove the ioctls from these.  I haven't really
  decided on the name space.  I want to make sure that /dev does not
  change.</p>

<p><strong class="speaker">Julian</strong> : Have you considered using
  the earlier discussed methods and inheritance so that this all works
  together?</p>

<p><strong class="speaker">PoulHK</strong> : I discounted them for
  performance reasons.  I discounted newbus because it has a one way
  tree.  The one thing we're having a lot of problems now is something
  going away.  That does not work today.</p>

<p><strong class="speaker">Julian</strong> : How do you handle the
  case when the device rips out at the bottom when you've got a
  downwards going command?</p>

<p><strong class="speaker">PoulHK</strong> : There's two things to it.
  A struct bio traveling down will either be in the consumer or the
  provider and that's where the lock is.  Modules can also be shut off
  safely.</p>

<p><strong class="speaker">Alfred</strong> : Couldn't you just provide
  a generic callback?</p>

<p><strong class="speaker">PoulHK</strong> : I can do that because
  they're all sitting in the module.  I need to negotiate with the
  device driver writers about that.</p>

<p><strong class="speaker">Nik C</strong> : Is this an implementation
  based on new research work or wholly new?</p>

<p><strong class="speaker">PoulHK</strong> : I've read what I could
  find but most current systems have a fixed hierarchy.</p>

<p><strong class="speaker">Robert</strong> : Will this give us a
  chance to retrofit the system with 64 bits?</p>

<p><strong class="speaker">PoulHK</strong> : struct bio will have 64
  bit numbers.</p>
</div>
</div>

<div class="topic">
<hr>
<a name="network"></a>
<h2>Network Stack - Luigi Rizzo</h2>

<p>Recent work has been on performance.  Removal of unnecessary
  copies.  Using clusters etc.  There is the polling code but it's
  only on a few devices.  Need to add support for more devices.</p>

<p>Do people like polling?</p>

<div class="discussion">
<p><strong class="speaker">PoulHK</strong> : I worry about
  interactions with the rest of the system.  We should probably spend
  some time looking at that.</p>

<p><strong class="speaker">Luigi</strong> : The next thing to do is
  add mixed mode operation.</p>
</div>

<p>Jonathan has something to say about how network interrupts are
  dispatched.</p>

<p>Some minor fixes to the stack.  FIFO buffers on UDP </p>

<p>I have a version of PGM (reliable multicast).  I plan to commit to
  current and stable if people ask.</p>

<p>The ICSI folks have changes to multicast API which will help with
  IGMPv3.</p>

<p>Some of this code I do for myself.  How do we do kernel
  patches?</p>

<h3>Questions</h3>

<div class="discussion">
<p><strong class="speaker">Alfred</strong> : There's two things.  With
  256byte MBUFS and clusters for DMA people are seeing really bad
  utilization of memory for networking packets.  Certain application
  servers with small packets have problems.</p>

<p><strong class="speaker">Luigi</strong> : I've talked to Peter Wemm
  about this stuff.</p>

<p><strong class="speaker">Julian</strong> : First, I have some times
  worried about the flexibility of polling regarding different
  networking types.  For instance the number of packets on Gigabit
  vs. PPP.  I'm worried about the extremes.</p>

<p><strong class="speaker">Luigi</strong> : This will become
  completely irrelevant when I implement mixed mode.</p>

<p><strong class="speaker">Julian</strong> : Second is to do with the
  TCP stack trying to remove copies.  Have you got any intention of
  evaluating the recent SACK implementation?</p>

<p><strong class="speaker">Luigi</strong> : That broke standard TCP.</p>
  
<p><strong class="speaker">Alfred</strong> : Actually SACK is out of
  style now.  One other thing on performance is that the drivers do a
  mget/mclget at once.</p>

<p><strong class="speaker">Julian</strong> : Third question is the
  ability to add meta data to packets using m_aux?</p>

<p><strong class="speaker">Luigi</strong> : My major concern is that a
  generic system is very slow because of scanning for data.</p>

<p><strong class="speaker">Robert</strong> : I think that that's worth
  doing.  Julian will you own that?</p>

<p><strong class="speaker">Julian</strong> : Yes.</p>
  
<p><strong class="speaker">Anon</strong> : Impact of polling scheme on
  SMP?</p>

<p><strong class="speaker">Luigi</strong> : They don't compile
  together.  Right now I only have one polling loop.  With a giant
  lock around the stack what's the point?</p>

<p><strong class="speaker">PoulHK</strong> : To what extent do we want
  to use the netgraph code?  How do we deal with the multiple ATM
  stacks.</p>

<p><strong class="speaker">Warner</strong> : Lets lose the ones that
  don't work.</p>

<p><strong class="speaker">PoulHK</strong> : None of them work
  now.</p>

<p><strong class="speaker">Greg</strong> : Just losing them could get
  us into a bounce.  Maybe we should try to encourage using it.</p>

<p><strong class="speaker">PoulHK</strong> : Is ATM interesting to
  FreeBSD at all?</p>

<p><strong class="speaker">Gnn</strong> : ATM is necessary for DSL</p>
  
<p><strong class="speaker">Justin</strong> : What about DAFS?  That
  uses ATM.</p>

<p><strong class="speaker">Julian</strong> : Since our end user
  community does not use 5.0 that's part of the problem.</p>

<p><strong class="speaker">PoulHK</strong> : It's a perfectly valid
  point.  Who's going to fix it?</p>

<p><strong class="speaker">Anon</strong> : The ATM list is somewhat
  active.</p>

<p><strong class="speaker">PoulHK</strong> : There are two stacks one
  that is used by the Japanese and one that does a bunch of weird
  stuff that no one uses.</p>

<p><strong class="speaker">Robert</strong> : Action item is to query
  the atm list to see what's up with this.</p>

<p><strong class="action">Action Item</strong> : Query the ATM list
  about which stack they want/use.</p>

<p><strong class="speaker">Julian</strong> : We want to be careful
  about ripping it out if people are using it with DSL cards.</p>

<p><strong class="speaker">Warner</strong> : One of the weaknesses in
  the current network stack is dealing with removable devices.</p>

<p><strong class="speaker">Peter</strong> : You have to eject a button
  on M$.  Laughter.</p>

<p><strong class="speaker">Robert</strong> : Part of the problem is
  the ifnet pointers from mbufs etc.  We do need a long term solution.
  If you ifconfig down that doesn't fix it.</p>

<p><strong class="speaker">Luigi</strong> : You could try to keep the
  ifnet structure alive.  Dummynet can scan all the mbufs whenever you
  delete a pipe.  It's expensive but you could do it on eject.</p>

<p><strong class="speaker">Alfred</strong> : The drivers have to be
  more robust.</p>

<p><strong class="speaker">Julian</strong> : I actually did some work
  on adding reference counts to all consumers of ifnet structures.  It
  reference counted everything but it didn't cause a performance
  issue.</p>

<p><strong class="speaker">Luigi</strong> : This becomes an issue only
  at higher speeds.</p>

<p><strong class="speaker">Robert</strong> : We may want to defer this
  to SMPng.</p>

<p><strong class="speaker">Gnn</strong> : You could have a two level
  hierarchy of device drivers.</p>

<p><strong class="speaker">Terry</strong> : Virtual interfaces.</p>
  
<p><strong class="speaker">PoulHK</strong> : This ties into another
  issue about how we look at our interfaces.  No one notices when I
  unplug my device.</p>

<p><strong class="speaker">Peter Wemm</strong> : The problem isn't
  deleting the routes its adding more routing messages.</p>

<p><strong class="speaker">Nick S</strong> : Also includes
  dhclient.</p>

<p><strong class="speaker">Gnn</strong> : Need new routing messages.</p>
  
<p><strong class="speaker">Paul Richards</strong> : Wants activities
  brought up to userland for devd.</p>

<p><strong class="speaker">Anon</strong> : At BEOS we had the user
  list all the potential interfaces.</p>

<p><strong class="speaker">Robert</strong> : I think we still need a
  routing socket event.</p>

<p><strong class="speaker">All</strong> : Discuss on mailing list.</p>
  
<p><strong class="speaker">Jonathan L</strong> : If we're talking
  about doing this with cables this works with MII but it's only in
  kevent and not in routing sockets.</p>

<p><strong class="speaker">Matt</strong> : Having a carrier loss flag
  an existing route is the right answer.</p>

<p><strong class="speaker">PoulHK</strong> : Re raise netgraph issue.
  What is the future of netgraph in the tree right now.  We have very
  few users now.</p>
	
<p><strong class="speaker">Julian</strong> : What parts are not
  done?</p>
  
<p><strong class="speaker">PoulHK</strong> : Configuration etc.</p>
  
<p><strong class="speaker">Alfred</strong> : Netgraph is extremely
  useful.  It needs to be documented and a bit more bolted down.</p>

<p><strong class="speaker">Julian</strong> : It is bolted down.  For
  5.0 only one API changed.  There's plenty of documentation.</p>

<p><strong class="speaker">Peter W</strong> : Originally when it first
  came up it was not meant for high speed.</p>

<p><strong class="speaker">Julian</strong> : I was being cautious.  We
  could switch over all of PPP to use it etc.</p>

<p><strong class="speaker">Nick S</strong> : I'd like to see the mpd
  netgraph configuration files become more /usr/sbin/ppp.</p>

<p><strong class="speaker">Julian</strong> : Brian has been toying
  with having ppp take over mpd.

<p><strong class="speaker">Gnn</strong> : Can we use netgraph for SMP?
  
<p><strong class="speaker">Peter W</strong> : I'm a refugee from a
  streams based system.  It's scary.  Be a little bit careful.</p>

<p><strong class="speaker">Terry</strong> : I think it would be very
  hard to for example take the Rice work and make it work in the
  context of netgraph where you're processing interrupts to
  completion.  The advantage of going to completion.</p>

<p><strong class="speaker">Luigi</strong> : I think I'm doing the same
  thing .</p>

<p><strong class="speaker">Jonathan L</strong> : I have code that does
  that.  I've replaced all the queuing calls with a single call.</p>

<p><strong class="speaker">Robert</strong> : Bring this to an end.</p>
</div>
</div>

<h2>LUNCH</h2>

<div class="topic">
<hr>
<a name="trustedbsd"></a>
<h2>TrustedBSD - Robert Watson</h2>

<p>DARPA funding has accelerated work.</p>

<p>Goal is to introduce security features for new consumers.</p>

<p>Most basic component is ACL work (fine grained ACLs).  We needed
  extended attributes, so those are in too.  Currently low performance
  and low reliability.  Userland still needs new utilities.</p>

<p>The more interesting work is in the Mandatory Access Control.  Goal
  is to enforce new restrictions in the kernel.  Multi-level security
  uses this.</p>

<p>Part of the work is to port SE Linux stuff to BSD.</p>

<p>This stuff interacts with other subsystems including the network.</p>

<p>Mandatory policies.  Discretionary rights are you protecting your
  own data.  This is very hard to manage.  MAC addresses this by
  defining policies for users in the system.  Where you have many
  users on the same machine.  There are a couple of traditional
  systems that are in military systems and trusted systems.</p>

<p>MLS is a confidentiality policy.  Who can read/write things based
  on clearance.  Doing things based on the "need to know."</p>

<p>BIBA integrity system is the other.  Secure levels are somewhat
  like this but are not comprehensive.</p>

<p>Type Enforcement.  Flexible MAC based on administrator rules.</p>

<p>You can plug different models into the framework.</p>

<p>MAC requires pervasive enforcement.  Current system can restrict
  access to interfaces.  Can mark packets for security.  Can control
  sockets.</p>

<p>What the framework does is provide a single framework to plug these
  into.</p>

<p>The framework provides APIs.  You put these throughout the code.
  They are ifdef'd.  If you don't compile with "options mac" you don't
  get this.</p>

<p>What happens with the framework a module can declare at boot time or
  you can do an LKM on it.</p>

<p>Right now these API calls are in a perforce branch.  They are
  pervasive.  They don't touch every part of the system, only the
  parts that NAI use.</p>

<p>There isn't a generic label structure.  To add new labels you must
  recompile the kernel.  Real key is to keep the costs low.</p>

<p>We don't allow for garbage collection on labels.  Binary block that
  gets carried around.</p>

<p>This is not really integrated into userland.</p>

<p>Reduced the number of total security checks in the kernel by
  unifying on this i/f.</p>

<div class="discussion">
<p><strong class="speaker">PoulHK</strong> : Does this flexibility
  include removing the existing checks?</p>

<p><strong class="speaker">Robert</strong> : No.  You can only extend
  checks.</p>

<p>Directions are flexibility , add more hooks in to the MAC for the
  kernel, integrate other work like LOMAC.  Need to teach userland
  something.</p>

<p><strong class="speaker">Alfred</strong> : Are you moving to per
  operation?</p>

<p><strong class="speaker">Robert</strong> : Right now we only do at
  open() time.  We want to do read/write and send/recv.</p>

<p><strong class="speaker">Robert</strong> : Once we have read and
  write we'll be able to revoke access.</p>

<p>We'd like to commit this before 5.0.  It's available in PerForce.
  PerForce now exports through cvsup.</p>

<p>We have not done any micro-benchmarks.  Once we know then we can
  make a decision to leave it on or not.</p>

<p><strong class="speaker">Alfred</strong> : What about active mode
  tripwire like system?</p>

<p><strong class="speaker">Robert</strong> : You can do a number of
  things like that with the current framework.</p>

<p><strong class="speaker">PoulHK</strong> : One of the other things I
  would like to do is a best effort MD5 on files.  This would make
  tripwire and mtree checks faster.</p>

<p><strong class="speaker">Robert</strong> : The problem with that is
  you don't get the data during these operations.</p>

<p>Right now the struct mbuf is extended but it would be nice to have
  a better system.</p>

<p><strong class="speaker">Alfred</strong> : m_aux</p>
  
<p><strong class="speaker">Robert</strong> : sounds expensive because
  of the list stuff</p>

<p><strong class="speaker">Terry</strong> : You said something about
  the NSA linux code.  Independent?  Licensing?</p>

<p><strong class="speaker">Robert</strong> : Interesting issue.  All
  TrustedBSD work is under BSD license.  The NSA stuff will not be
  under a BSD license but will be a module.</p>

<p><strong class="speaker">Terry</strong> : By compiled do you mean a
  loaded module?  Binaries?</p>

<p><strong class="speaker">Robert</strong> : Not binary, you could
  imagine a package.</p>

<p><strong class="speaker">Anon</strong> : My understanding was that
  any project done by the gov't was PD.  But that doesn't seem to be
  OK.</p>

<p><strong class="speaker">Robert</strong> : I can't say.  Part of our
  contract was to release as open source.</p>

<p><strong class="speaker">Alfred</strong> : About compatibility.  How
  compatible are we with others?</p>

<p><strong class="speaker">Robert</strong> : We've tried to follow the
  specs.</p>

<p><strong class="speaker">Alfred</strong> : Perhaps support NFS
  extended attribute stuff?</p>

<p><strong class="speaker">Robert</strong> : Right now everyone does
  RPCs for ACLs and they're incompatible.  Not in Posix 1e.  We tried
  to work with others but some are not tracking (Linux).</p>
</div>
</div>

<div class="topic">
<hr>
<a name="capabilities"></a>
<h2>Capabilities - Brian Feldman</h2>

<p>Largely complete and stable.  Unknown performance hit.</p>
</div>

<div class="topic">
<hr>
<a name="kse"></a>
<h2>KSE - Julian Elischer</h2>

<p>Very quick status report.  It's an attempt to produce support for
  high quality threading within the kernel.  Threading is outside the
  kernel, the support is inside.  Taking advantage of work by Anderson
  (Scheduler Activations).  NetBSD is sticking closer to the paper.
  We're doing a variant based on discussions with a lot of people.
  The basic concept is the same.</p>

<p>The threading comes with the ability to make async syscalls.  Any
  syscall you do from the point of the view of the thread looks like
  its stopped but this does not stop the whole process.  A new thread
  is produced on the fly.  We've extended this to produce multiple
  upcall points, 1 per CPU.  This is so you can run multiple upcalls
  on different CPUs.  The upcalls occur to different stack contexts.</p>

<h3>Status Report</h3>

<p>There are a set of patches available on Julian's website.  Gets us
  as far as pthread.  Kernel supported, single CPU, threads.  All
  syscalls are async, but only on one CPU at a time.</p>

<p>This was shown in the WIP.</p>

<p>Up next is to do multi-processor.</p>

<p>Next stage is to make it complete or even safe.  What I've got
  works but I've broken ptrace so we can't debug processes.  What I
  have checked in are a number of changes that were part of this
  change.  This reduces the amount of diffs vs. the patch.  It's not a
  terribly huge diff at the moment.</p>

<p>Next is to get gdb working again.</p>

<p>The next change would be to make the changes for multiple CPUs.</p>

<p>Need a more complete version of the API.  Just have thread creation
  and thread kill right now.</p>

<p>I'm expecting that I'll have the current stuff checked in within
  the month.  Depends on issues with gdb.  I'm hoping June or July for
  the full multi-processor version.</p>

<p>I hope to check in soon so that user land folks can work with
  it.</p>

<h3>Questions</h3>

<div class="discussion">
<p><strong class="speaker">Julian</strong> : Does anyone think this is
  a bad idea?</p>

<p><strong class="speaker">Greg</strong> : We never finished our
  discussion on Tuesday.  3 layers is too many.</p>

<p><strong class="speaker">Julian</strong> : There are 4 layers but 2
  are basically null.</p>

<p><strong class="speaker">John</strong> : We talked about this, it is
  the right thing.</p>

<p><strong class="speaker">PoulHK</strong> : Sounds like a blue print
  paper.</p>

<p><strong class="speaker">Alfred</strong> : What do you plan on
  implementing in the upcall?</p>

<p><strong class="speaker">Julian</strong> : It's not an explicit call
  to allocate and deallocate threads.  You do a call which says "I'm
  going to go into this mode" and when something blocks come back to
  me as an Nth or an N+1.</p>

<p><strong class="speaker">Alfred</strong> : OK.</p>
  
<p><strong class="speaker">Peter W</strong> : It works just like fork
  except instead of retuning just once in the parent/child it returns
  over and over again.</p>

<p><strong class="speaker">Matt</strong> : What I would like you to do
  is to provide us how much this simplifies the user land thread
  library.</p>

<p><strong class="speaker">Julian</strong> : Just to get basic threads
  on normal code (reads, writes, anything that could block) there is a
  set of code (~5000 lines of C) that has to keep track of this.  The
  entire user land thread scheduler is 10 lines.</p>

<p><strong class="speaker">Peter W</strong> : The user level thread
  scheduler only works for networking but dies on disk stuff.</p>

<p><strong class="speaker">Robert</strong> : You get disk I/O
  parallelism.</p>

<p><strong class="speaker">Alfred</strong> : I'd like to still be able
  to use user land threading for networking.</p>

<p><strong class="speaker">Julian</strong> : There is no point in not
  using.  All we're allocating for you is a stack.</p>

<p><strong class="speaker">Matt</strong> : There is a partitioning
  here.  In I/O reading there is a problem, but in writing there is
  not.  Only 1% of writes now block.  If you're reading 1000s of
  sockets there is an issue.</p>

<p><strong class="speaker">Robert</strong> : KSEs are very general.
  Doing the basic stuff is the right answer.</p>

<p><strong class="speaker">Julian</strong> : My theory is in fact that
  we'll keep the current code and provide a new library.  I don't want
  to be responsible for the entire threading system.</p>

<p><strong class="speaker">Matt</strong> : We can always change the
  default.</p>

<p><strong class="speaker">Julian</strong> : Just as an aside.  As
  part of this work I had to rearrange the way in which threads are
  done.  We now have a pool of free threads.  It turns out that I now
  have a cache of threads.  Thread reapers go in wait() (called by
  exit()).</p>

<p><strong class="speaker">Nick S</strong> : Corner case.  Simple app
  that you register KSE callback thing and then it makes a call into a
  blocking syscall and blocks.</p>

<p><strong class="speaker">Julian</strong> : That thread is blocked.</p>
  
<p><strong class="speaker">Nick S</strong> : What happens when there
  is nothing to do?</p>

<p><strong class="speaker">Julian</strong> : It calls yield() and gets
  discarded.  There is a mailbox between that could be used to tell
  the kernel "never call me" when the process knows that its
  blocked.</p>

<p><strong class="speaker">Greg</strong> : What are the performance
  implications?</p>

<p><strong class="speaker">Julian</strong> : None.</p>
  
<p><strong class="speaker">Peter W</strong> : For disk performance it
  will be great.</p>

<p><strong class="speaker">Julian</strong> : For a non-threaded
  process on a non-KSE kernel I can't see any difference.</p>

<p><strong class="speaker">Robert</strong> : Questions on the
  phone?</p>

<p><strong class="speaker">Phone</strong> : At what level does user
  land thread scheduler operate?</p>

<p><strong class="speaker">Julian</strong> : It's a library that you
  link with.</p>

<p><strong class="speaker">Phone</strong> : What about other
  languages?</p>

<p><strong class="speaker">Julian</strong> : You need to write the
  library.  It's all very short.</p>

<p><strong class="speaker">Warner</strong> : Does this mean it breaks
  the one application that we have that's not written in C?</p>

<p><strong class="speaker">Peter W</strong>: cvsup will work.</p>
</div>
</div>

<div class="topic">
<hr>
<a name="smpng"></a>
<h2>SMPng - John Baldwin</h2>

<p>I actually attempted to set up a BOF on this at the conference.
  The biggest topic of discussion was "how much do we expect of have
  done by 5.0?"  A very conservative viewpoint is:</p>

<p>Overhaul process cred stuff.</p>

<p>Finish ktrace to work in an async kthread</p>

<p>Networking stack because its part of the target market and is a big
  net gain.</p>

<p>Much of the discussion centered around sockets.</p>

<p>Another suggestion was to trace down VOP read and write path and
  push down giant into that.</p>

<p>The last thing would be to make the kernel fully preemptable.</p>

<div class="discussion">
<p><strong class="speaker">Greg</strong> : Where is the architectural
  overview?</p>

<p><strong class="speaker">John</strong> : I'm working on that.</p>
  
<p><strong class="speaker">Greg</strong> : What about light weight
  interrupts?</p>

<p><strong class="speaker">John</strong> : No real need.</p>
  
<p><strong class="speaker">Greg</strong> : I think we're going to fail
  unless we have a good theoretical base.</p>

<p><strong class="speaker">David</strong> : You've told us 3 things
  you've wanted for 5.0.  These are micro-goals.  What is the big
  picture?</p>

<p><strong class="speaker">John</strong> : The direction is a "fine
  grained locked kernel".</p>

<p><strong class="speaker">PoulHK</strong> : I'm sure we can come up
  with an architectural paper.  Very little of 4BSD ever made it in
  either.  I don't believe that can we make a full map.</p>

<p><strong class="speaker">Greg</strong> : I think we can.</p>
  
<p><strong class="speaker">PoulHK</strong> : We're talking about
  redoing sections of code.</p>

<p><strong class="speaker">John</strong> : What key milestones?</p>
  
<p><strong class="speaker">Greg</strong> : Light weight threads.</p>
  
<p><strong class="speaker">Peter/John</strong> : Already done.</p>
  
<p><strong class="speaker">Justin</strong> : Having been at the SMPng
  meeting the general consensus was to come up with a framework.  LWT
  is an optimization.  Maybe only to 2 CPUs at 5.0</p>

<p><strong class="speaker">David</strong> : What is it that you've
  accomplished from a high level?</p>

<p><strong class="speaker">John</strong> : Almost all the work is
  infrastructure.  When BSD/OS did SMP they added mutexes and are
  using lock manager locks.</p>

<p><strong class="speaker">Bosko</strong> : LWI for x86 we just switch
  contexts it has a very minimal impact.  The code is available</p>

<p>We don't generate code on the fly.</p>

<p><strong class="speaker">John</strong> : Current Status cont.
  We've taken more time to get it right.  We've added common things
  like semaphores, reader writer locks.  I've been making the kernel
  fully pre-emptible.  I've committed half of this to current now.  The
  ktrace is another infrastructural issue so its feasible.</p>

<p><strong class="speaker">David</strong> : Then general framework
  will be done by 5.0.  Second to test the infrastructure you've been
  locking the proc structure.  For 5.0 we're still not talking about
  super strong, fine grained SMP.</p>

<p><strong class="speaker">John</strong> : That's why we want to do
  the network stuff.</p>

<p><strong class="speaker">PoulHK</strong> : Geom and devfs can do
  this now.  We don't need to wait.  We have various pieces of code in
  the tree that can be taken out from under giant.</p>

<p><strong class="speaker">Matt</strong> : Just an example of what
  we'll probably be able to do fairly soon are the fsops in the file.
  For things like pipes, /dev/null/, /dev/zero.  The i/o paths we have
  to concentrate on the most are read/write for vfsops.  If we can't
  fine grain the others in 5.0 oh well.</p>

<p><strong class="speaker">Anon</strong> : What specifically are you
  planning in terms of performance gains before the release?  Do we
  have any more firm of a schedule?</p>

<p><strong class="speaker">John</strong> : 2nd question (schedule) is
  for later discussion.  1st is "no more than 5% loss."  I want to run
  some real benchmarks.</p>

<p><strong class="speaker">Warner</strong> : What benchmark are you
  going to use?</p>

<p><strong class="speaker">Luigi</strong> : What if we totally miss
  the numbers?</p>

<p><strong class="speaker">John</strong> : We'll have to revisit the
  whole release.</p>

<p><strong class="speaker">Peter</strong> : Turning spls into mutexs
  doesn't help us.</p>

<p><strong class="speaker">John</strong> : spls as mutexes still don't
  get us out from giant.</p>

<p><strong class="speaker">PoulHK</strong> : I need documentation.</p>
  
<p><strong class="speaker">Anon</strong> : I will be happy to help you
  with words.</p>

<p><strong class="speaker">Warner</strong> : I signed up to do locking
  for newbus.</p>

<p><strong class="speaker">Paul Richards</strong> : I'll help on
  documentation.  We still need a roadmap.</p>

<p><strong class="speaker">Robert</strong> : The one thing on the must
  lock list is the network.</p>

<p><strong class="speaker">PoulHK</strong> : We can just put one lock
  around the network.</p>

<p><strong class="speaker">Nick S</strong> : On a uniprocessor the
  locks are just null right?</p>

<p><strong class="speaker">John</strong> : Yes on spin locks.</p>
  
<p><strong class="speaker">Nick S</strong> : Nevermind.</p>
  
<p><strong class="speaker">Luigi</strong> : Do we care about
  performance on uniprocessors on 5.0?</p>
	
<p><strong class="speaker">John</strong> : One thing that SMPng may
  help buy is that if you have two network interfaces then you can
  handle more stuff.</p>

<p><strong class="speaker">Luigi</strong> : Do we care or not about
  uniprocessor on 5.0.</p>

<p><strong class="speaker">John</strong> : Yes</p>
  
<p><strong class="speaker">Julian</strong> : In the uniprocessor case
  KSE degrades down to forkeed processors.</p>

<p><strong class="speaker">Peter W</strong> : Need a graph of the
  locking the subsystems.</p>
</div>
</div>

<h4>Break</h4>

<div class="topic">
<a name="releng"></a>
<h2>5.0 Release Engineering - Murray Stokely</h2>

<p>There are a number changes to the team.  Murray, Robert, John,
  Bruce Mah.  Change review committee.  Documented the process.</p>

<p>We think its pretty important to take a more active role.  Want to
  do developer previews (polished snapshot).  April 1 will be preview
  1.  Goals are:</p>

<ul>
  <li>2 week feature freeze to current and then branch</li>
  <li>Going to do 4.6 in June, 4.7 in October, and 4.8 in Feb 2003.</li>
  <li>Developer preview 2 in June around Usenix.</li>
  <li>For architectures we hope to do Sparc64 on April 1.</li>
</ul>

<p>Got a bit of a feature list for 5.0 final.  SMPng is broken down
  into several sections.  UFS2. KSE.  PAM overhaul.  TrustedBSD etc.</p>

<p>I'd like some feedback on this.</p>

<h3>Discussion</h3>

<div class="discussion">
<p><strong class="speaker">Warner</strong> : Are we doing to try to
  have the developer release 2 done so we can hand out CDs at
  Usenix?</p>

<p><strong class="speaker">John</strong> : That might be pushing
  it.</p>
  
<p><strong class="speaker">Anon</strong> : Can we push Usenix back a
  bit? (Laughter)</p>

<p><strong class="speaker">David</strong> : Feature freeze is a code
  slush.  Will I as a committer see a freeze?</p>

<p><strong class="speaker">Murray</strong> : You will not have to
  worry about bug fixes but you must act rationally.</p>

<p><strong class="speaker">Paul R</strong> : Do we really need
  multiple release branches?</p>

<p><strong class="speaker">Robert</strong> : Good to have around.</p>
  
<p><strong class="speaker">Alfred</strong> : Could we reach a
  consensus on what sort of debugging will be in 5.0?</p>

<p><strong class="speaker">Robert</strong> : We want to get this to
  early access people.</p>

<p><strong class="speaker">Murray</strong> : This is an opt in thing
  anyway.</p>

<p><strong class="speaker">Alfred</strong> : We need a list of the
  debug options etc.</p>

<p><strong class="speaker">Warner</strong> : The cardbus will ship
  with debugging turned on but its tunable.</p>

<p><strong class="speaker">PoulHK</strong> : We need to know if we're
  going to turn off the a/j options on malloc3().</p>

<p><strong class="speaker">Doug</strong> : I don't know how tied you
  are to the release schedule.  If you want to spend all of October
  polishing.  If we go backwards from October we can do Release 1 on
  May 15.  April 1st is too soon and puts you in weird categories
  relative to Usenix.</p>

<p><strong class="speaker">Murray</strong> : The way we have it set up
  now... (Graphic)</p>

<pre>	April 1 (DP 1)

	June 9-14 (Usenix)

	June 25 (DP2)

	October 1st is Feature Freeze

	October 20th is Code Freeze

	Nov 20th 5.0 Release

ALTERNATE

	May 15 DP 1

	July DP 2</pre>

<p><strong class="speaker">Murray</strong> : The number of people
  running current is too small.</p>

<p><strong class="speaker">Paul Richards</strong> : Not much point in
  doing DP 1 if DP2 is totally different.</p>

<p><strong class="speaker">Murray</strong> : But that means that other
  non SMP stuff is still not in.</p>

<p><strong class="speaker">David</strong> : People are talking about
  what they're planning for 5.0 Perhaps you might to poll the people
  who have balls in the air.  Is there anything that April 1 is going
  to give us?</p>

<p><strong class="speaker">Murray</strong> : Wide spread testing.</p>
  
<p><strong class="speaker">Alfred</strong> : I think the sooner the
  better.</p>

<p><strong class="speaker">Justin</strong> : Why do we think that just
  because we put together a shrink wrap that people will use it?</p>

<p><strong class="speaker">Murray</strong> : Because its a discipline
  on all of us to get this stuff in there.  If we're moving towards a
  goal we need to do that.</p>

<p><strong class="speaker">Justin</strong> : This is not about the
  final release but about what is in the tree today.  Therefore the
  first preview is not an interesting release.</p>

<p><strong class="speaker">Murray</strong> : Its concrete steps
  towards 5.0 release.</p>

<p><strong class="speaker">Justin</strong> : I don't know that it's
  necessary.</p>

<p><strong class="speaker">Doug</strong> : We're going to have people
  generating bug reports against things that are spurious problem
  reports.</p>

<p><strong class="speaker">Warner</strong> : Cardbus vs. PCI interrupt
  routing is an example of this.</p>

<p><strong class="speaker">Justin</strong> : I guess the way I look at
  this is that we force productization is to force the date.  Why is
  it that on a daily basis that things suck so bad?</p>

<p><strong class="speaker">David</strong> : Why does it suck so bad?</p>
  
<p><strong class="speaker">Justin</strong> : Because people don't get
  shat on for breaking things.</p>

<p><strong class="speaker">Robert</strong> : Why does it suck?</p>
  
<p><strong class="speaker">Justin</strong> : I put it on my server and
  its slow.  Instead of fixing PCI interrupts.</p>

<p><strong class="speaker">PoulHK</strong> : I'd like to point out
  that we have substantial historical experience with all .0 releases.
  It is indisputable that a snapshot CDROM makes people run it.
  Getting something out there is crucial to the testing of CURRENT.
  If we simply call this current snapshot that will be best.  Set your
  date and roll your CD.</p>

<p><strong class="speaker">Gnn</strong> : These are different issues.</p>
  
<p><strong class="speaker">Justin</strong> : The people that used to
  complain about it but don't anymore.</p>

<p><strong class="speaker">Alfred</strong> : We have 4 more platforms,
  it's more difficult now.</p>

<p><strong class="speaker">Murray</strong> : We have build machines
  etc.</p>

<p><strong class="speaker">Justin</strong> : When I first joined
  people were in it because they had to do stuff incorrectly because
  they had to do things on time.  If we're going to engineer a real
  product then yeah, it's difficult but that's the reason why this is
  a cool project.  So just giving up and saying it is hard is BS.</p>

<p><strong class="speaker">Gnn</strong> : Process, process, process...</p>
  
<p><strong class="speaker">Julian</strong> : Breaking the build is not
  as bad as breaking the kernel.  What's harder is committing a
  subsystem that affects another subsystem.  In terms of the process
  I'd like to see a best practices document.  On how people develop
  patches etc.  A list of things you should do etc.</p>

<p><strong class="speaker">David</strong> : You can do that from
  freefall.</p>

<p><strong class="speaker">Julian</strong> : As soon as I find out its
  broken I'll fix it.</p>

<p><strong class="speaker">David</strong> : I have posted them many
  times.</p>

<p><strong class="speaker">Justin</strong> : One other thing I would
  suggest is that instead of becoming active only during release you
  should be doing this full time.  If people start putting stuff in
  the tree today that's not going in to 5.0 then slap their hands.
  Make a window so that people...</p>

<p><strong class="speaker">Peter</strong> : The Mozilla tackled the
  build problems with tinderbox.  This will solve a lot of
  problems.</p>

<pre>	while (1)
	{
	      build
	      if (break)
		 send mail to those who committed most recently
	      else
	         clear list of recent committers
	}</pre>

<p><strong class="speaker">Nick S</strong> : The suggestion that
  tangential features should be barred until after 5.0 bugs me.</p>

<p><strong class="speaker">Justin</strong> : It should not be your
  arbitrary decision.  It should be whatever body is empowered to make
  that decision.</p>

<p><strong class="speaker">Robert</strong> : We're using the Usenix to
  November window.</p>

<p><strong class="speaker">Paul Richards</strong> : This is a
  volunteer project.  In our volunteer time we wanted to what we
  couldn't do in our normal jobs.  Volunteers will do things by rules.</p>

<p><strong class="speaker">PoulHK</strong> : This project was started
  by people for fun.  Every time you use the word enforce you get
  fun--.  It is much better to inspire than to enforce.  You should
  not let people get away with things.  I hate to say this but some
  times you need to slap fingers.  Many times people will thank you
  for it.  We see it again that people go off and need to be brought
  back.</p>

<p><strong class="speaker">Robert</strong> : We have 10 minutes left.
  Let's wrap up.</p>

<p><strong class="speaker">Paul Richards</strong> : Can we take
  Justin's proposal?</p>

<p><strong class="speaker">Peter</strong> : Going from chaos to clamp
  down.  This can push a code fork.</p>

<p><strong class="speaker">Doug</strong> : One is that in regards to
  PoulHK said in addition to the potential cost of disciplining a
  committer you have to measure the cost against the others who want
  that person gone.  How many more people could we attract if that
  stress wasn't present.</p>

<p><strong class="speaker">Justin</strong> : You either have a good
  manager or a bad manager.  Good managers trust you.  Are the people
  in the release engineering team going to be good managers?</p>

<p><strong class="speaker">Peter</strong> : The MFC process seems to
  work nicely but going further may not be the best idea.</p>

<p><strong class="speaker">Robert</strong> : Do you think the schedule
  is going too far?</p>

<p><strong class="speaker">Julian</strong> : Usenix may not be such a
  large audience to worry about.  People there are technical enough.
  On how many snapshots we have.  I've been wondering whether we
  should have 5.0 on the disc but 5.0 and the cvs tree and cvsup so
  people can easily upgrade.  Bootstrap CDs.</p>

<p><strong class="speaker">Murray</strong> : Any issues with the
  name?</p>

  
<p><strong class="speaker">PoulHK</strong> : Why not snapshot?</p>
  
<p><strong class="speaker">Warner</strong> : I think the dates look
  good but I would pick a different.</p>
</div>
</div>

<div class="topic">
<hr>
<a name="conclusion"></a>
<h2>Concluding Remarks - Robert Watson</h2>

<div class="discussion">

<p><strong class="speaker">Robert</strong> : Should we do another of
  these at Usenix?</p>

<p><strong class="speaker">All</strong> : Yes.</p>
  
<p><strong class="speaker">John</strong> : 2 days?</p>
  
<p><strong class="speaker">Robert</strong> : What could we do
  better?</p>

  
<p><strong class="speaker">Sundry</strong> : parking validation,
  connectivity, projector, catered lunch, ...</p>

<p><strong class="speaker">PoulHK</strong> : I would like to propose
  we make a formal hour every month to talk about on irc?</p>
</div>
</div>

  &footer;
  </body>
</html>
