os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
doc/en/events/2002/bsdcon-devsummit.sgml
Hiroki Sato cfd9e12239 www cleanup mega commit: 
- Move includes.nav*.sgml to share/sgml/navibar.ent and
   <lang>/share/sgml/nabibar.l10n.ent.

 - Move includes.sgml and includes.xsl to
   share/sgml/common.ent, share/sgml/header.ent, <lang>/share/sgml/l10n.ent,
   and <lang>?share/sgml/header.l10n.ent.

 - Move most of XSLT libraries to share/sgml/*.xsl and
   <lang>/share/sgml/*.xsl.

 - Move news.xml and other *.xml files for the similar purpose
   to share/sgml/*.xml and <lang>/share/sgml/*.xml.

 - Switch to use a custom DTD for HTML document.  Now we use
   "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension", which is
   HTML 4.01 + some entities previously pulled via
   "<!ENTITY % includes SYSTEM "includes.sgml"> %includes;" line.
   The location of entity file will be resolved by using catalog file.

 - Add DOCTYPE declearation to XML documents.  This makes the followings
   possible:

   * Use of &foo; entities for SGML in an XML file instead of defining
     {$foo} as the same content.

   * &symbolic; entities for Latin characters.

 - Duplicated information between SGML and XML, or English and
   translated doc, has been removed as much as possible.
2006-08-19 21:20:54 +00:00

1921 lines
68 KiB
Text
Raw Blame History

<!DOCTYPE HTML PUBLIC "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension//EN" [
<!ENTITY base CDATA "../..">
<!ENTITY date "$FreeBSD: www/en/events/2002/bsdcon-devsummit.sgml,v 1.11 2005/10/04 17:22:00 blackend Exp $">
<!ENTITY email 'hackers'>
<!ENTITY title "BSDCon 2002 FreeBSD Developer Summit">
<!ENTITY % navinclude.about "INCLUDE">
<!ENTITY % developers SYSTEM "../../developers.sgml"> %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>
Reference in a new issue View git blame Copy permalink