52f6d56540
- Replace /XML/{doc,www}/ with /XML/ in SysId.
- Remove empty stylesheets in share/xsl and point share/xml/empty.xsl via
XML catalog instead.
- Change the L10N layer in freebsd-*.xsl not to use localized XSLT
stylesheets directly.
- Move share/xsl/* to share/xml and remove share/xsl.
- Remove obsolete share/web2c/pdftex.def.
1924 lines
68 KiB
XML
1924 lines
68 KiB
XML
<?xml version="1.0" encoding="iso-8859-1"?>
|
|
<!DOCTYPE html PUBLIC "-//FreeBSD//DTD XHTML 1.0 Transitional-Based Extension//EN"
|
|
"http://www.FreeBSD.org/XML/share/xml/xhtml10-freebsd.dtd" [
|
|
<!ENTITY email 'hackers'>
|
|
<!ENTITY title "BSDCon 2002 FreeBSD Developer Summit">
|
|
]>
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<title>&title;</title>
|
|
|
|
<cvs:keyword xmlns:cvs="http://www.FreeBSD.org/XML/CVS">$FreeBSD$</cvs:keyword>
|
|
</head>
|
|
|
|
<body class="navinclude.about">
|
|
|
|
<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>
|
|
|
|
<p><strong class="speaker">Benno</strong> : On the subject of PPC I'd
|
|
be willing to offer them.</p>
|
|
|
|
<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>
|
|
|
|
<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>
|
|
|
|
<p><strong class="speaker">Gnn</strong> : Can we use netgraph for SMP?</p>
|
|
|
|
<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>
|
|
|
|
</body>
|
|
</html>
|