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.
1143 lines
39 KiB
XML
1143 lines
39 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 break '<div xmlns="http://www.w3.org/1999/xhtml"><hr/><center>BREAK</center><hr/></div>'>
|
|
<!ENTITY title "Usenix 2002 FreeBSD Developer Summit III">
|
|
]>
|
|
|
|
<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 third FreeBSD Developer Summit was held on June 11-12, 2002, at
|
|
the Monterey Marriott in Monterey, CA, immediately prior to the USENIX
|
|
Annual Technical Conference at the same location. The FreeBSD
|
|
Developer Summit was sponsored by DARPA, the <a
|
|
href="http://www.freebsdfoundation.org">FreeBSD Foundation</a>, <a
|
|
href="http://www.freebsdmall.com/">FreeBSD Mall</a>, Network
|
|
Associates Laboratories, and AT&T. Notes were taken by George
|
|
Neville-Neil, <a href="http://people.FreeBSD.org/~bmah">Bruce Mah</a>,
|
|
and <a href="http://www.FreeBSD.org/~rwatson">Robert Watson</a>.
|
|
Markup by <a href="http://www.FreeBSD.org/~murray">Murray
|
|
Stokely</a>.</p>
|
|
|
|
<p>These notes cover day 2, which began at 9:30am, and ended at 5:00pm.</p>
|
|
|
|
<h2>Agenda</h2>
|
|
|
|
<ul>
|
|
<li>Opening Comments</li>
|
|
<li><a href="#kse">KSE</a></li>
|
|
<li>Break</li>
|
|
<li><a href="#smp">SMPng</a></li>
|
|
<li>PGP key signing</li>
|
|
<li><a href="#hw">New Hardware Architectures</a></li>
|
|
<li>Lunch</li>
|
|
<li><a href="#trust">TrustedBSD</a></li>
|
|
<li><a href="#releng">Release Engineering</a></li>
|
|
<li>Break</li>
|
|
<li><a href="#rc">RCng</a></li>
|
|
<li><a href="#open">Open Discussion</a></li>
|
|
</ul>
|
|
|
|
<p>NOTE: As usual I missed some names, please add those I missed.</p>
|
|
|
|
<h2>Attending:</h2>
|
|
|
|
<p>Committers in person:</p>
|
|
<ul>
|
|
<li>Robert Watson (rwatson)</li>
|
|
<li>Julian Elischer (julian)</li>
|
|
<li>John Baldwin (jhb)</li>
|
|
<li>Matt Dillon (dillon)</li>
|
|
<li>David O'Brien (obrien)</li>
|
|
<li>Jeffrey Hsu (hsu)</li>
|
|
<li>Jennifer Yang (jennifer)</li>
|
|
<li>Bosko Milekic (bmilekic)</li>
|
|
<li>Alfred Perlstein (alfred)</li>
|
|
<li>Doug Rabson (dfr)</li>
|
|
<li>Paul Saab (ps)</li>
|
|
<li>Brooks Davis (brooks)</li>
|
|
<li>Murray Stokely (murray)</li>
|
|
<li>Jonathan Mini (mini)</li>
|
|
<li>Takanori Watanabe (takawata)</li>
|
|
<li>Gordon Tetlow (gordon)</li>
|
|
<li>Gregory Shapiro (gshapiro)</li>
|
|
<li>Sam Leffler (sam)</li>
|
|
<li>Bruce Mah (bmah)</li>
|
|
<li>David Malone (dwmalone)</li>
|
|
<li>Ian Dowse (iedowse)</li>
|
|
</ul>
|
|
|
|
<p>Also in person:</p>
|
|
<ul>
|
|
<li>George Neville-Neil (gnn)</li>
|
|
</ul>
|
|
|
|
<p>On The Phone:</p>
|
|
<ul>
|
|
<li>Alan Cox (alc)</li>
|
|
<li>Warner Losh (warner)</li>
|
|
</ul>
|
|
|
|
<p>Via webcast:</p>
|
|
|
|
<p>Many people listened into the webcast and discussed the topics on
|
|
IRC.</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 we have tried to make those sections
|
|
understandable.</p>
|
|
|
|
<div class="topic">
|
|
<hr/>
|
|
<h2>09:30 Opening Remarks</h2>
|
|
</div>
|
|
|
|
<div class="topic">
|
|
<hr/>
|
|
<a name="kse"></a>
|
|
<h2>KSE - Julian Elischer</h2>
|
|
|
|
<p>KSE has not changed much since the last summit (Feb). The major
|
|
change is that upcalls works more like signals instead of like fork().
|
|
That is to say that you give the system a function pointer to call
|
|
instead of having the "return twice" semantics so that it supports
|
|
all architectures.</p>
|
|
|
|
<p>The names in the system are deliberately different from other
|
|
threading packages. This was to reduce confusion during
|
|
development.</p>
|
|
|
|
<p>The process structure has been broken into 4 parts. This is in
|
|
-CURRENT at the moment. It's still "really" one structure but is
|
|
being accessed as 4 different ones.</p>
|
|
|
|
<p>Looking for more people to run the code.</p>
|
|
|
|
<p>Right now we're rewriting to clean up how the functions work.</p>
|
|
|
|
<p>Other architectures can be stubbed out as well.</p>
|
|
|
|
<p>Right now there is no support for Sparc or IA64 but he would like
|
|
to commit now. Not committing now means that it has to come out of
|
|
perforce and people have to patch it.</p>
|
|
|
|
<h3>Discussion</h3>
|
|
|
|
<div class="discussion">
|
|
|
|
<p><strong class="speaker">rwatson</strong> : What about userland?</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : It can run different threads
|
|
in userland. The primitives are all there it just needs a bit more
|
|
help. I would like to put an idea out. Is it a good idea to be able
|
|
to have non-threaded programs linking with threaded libraries?</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : Putting async I/O into such a
|
|
thing would make sense.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : The library would not care
|
|
who was accessing it.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : For instance libc could be
|
|
threaded or not.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : That would be interesting. I
|
|
don't know if the two interfaces are incompatible.</p>
|
|
|
|
<p><strong class="speaker">jhb</strong> : X does this.</p>
|
|
|
|
<p><strong class="speaker">dillon</strong> : It is very doable but you
|
|
have to make it non-preemptive. If you're switching non-preemptively
|
|
you can use library routines which are non threaded.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : If I do what I'm thinking of
|
|
doing then each lib will have its own KSE group.</p>
|
|
|
|
<p><strong class="speaker">dillon</strong> : stdio does not have to be
|
|
thread aware if you don't schedule preemptively. It all matters where
|
|
it blocks.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : Since you're a non-threaded
|
|
program you don't know that.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : If you're going to support
|
|
that, libc has to support threads.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : It sounds like some
|
|
complexity goes away. Can we use 1 libc with has threading?</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : Do we want to go down this
|
|
path?</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : Now or later?</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : What do I design now to do
|
|
this?</p>
|
|
|
|
<p><strong class="speaker">jhb</strong> : For example libc_r does not
|
|
work with rfork.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : The answer is that yes we
|
|
should move forward. Tricky issues, signals...</p>
|
|
|
|
<p><strong class="speaker">warner</strong> : Have people talked about
|
|
pthread programs and cancellation points?</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : The pthreads library does not
|
|
assume that you're only going to change threads at yield() points. We
|
|
are going to have cancellation points. There is an unimplemented call
|
|
which will be able to send a thread targeted signal even into the
|
|
kernel.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : When a thread is scheduled
|
|
onto a KSE there is a mailbox that the userland thread scheduler
|
|
updates.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : Is there anyone else who has
|
|
some time or test it? How many people should test this before I check
|
|
it in? There is a patch that's continuously updated on my web site to
|
|
be able to patch it to -CURRENT. There is a CVSUP target from cvsup
|
|
10 which will bring down the sources. If you go to my web page on
|
|
freefal there is a pointer there to a web page that explains how to
|
|
CVSUP from source.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : What about SMP locking for
|
|
this?</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : Handled by the proc locking.
|
|
Has not been tried on SMP machines yet.</p>
|
|
|
|
<p><strong class="speaker">obrien</strong> : What about on Sparc?</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : You may need to stub things
|
|
out.</p>
|
|
|
|
<p><strong class="speaker">jhb</strong> : Is the paper on the web site?</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : The updated copy has disappeared.</p>
|
|
|
|
<p><strong class="speaker">unknown</strong> : What's the different between
|
|
NetBSD and FreeBSD on this?</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : Logically not a tremendous
|
|
difference but Net follows the paper closely and Free takes the idea
|
|
and makes it into a production system. There were some tough battles
|
|
on -arch about this. The tricky point is that the proc structure has
|
|
to be broken into 4 instead of 2. If you want to be able to do POSIX
|
|
you need to be able to treated as different processes but in other
|
|
systems you need to group the threads. You wind up with two classes
|
|
of threads. You need another structure to do the aggregation. In the
|
|
end we ended up breaking up the proc structure into 4 pieces to not
|
|
overwhelm the CPU when scheduling threads. This is the major
|
|
difference.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : I greatly admire the NetBSD
|
|
way which is to take an idea and not dilute it.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : Net is also putting a Solaris
|
|
compatible threads package on top of their scheduler activations in
|
|
the Solaris ABI.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="topic">
|
|
<hr/>
|
|
<a name="smp"></a>
|
|
<h2>SMPng - John Baldwin</h2>
|
|
|
|
<div class="discussion">
|
|
|
|
<p><strong class="speaker">jhb</strong> : Yesterday we talked about SMP
|
|
related things so I'll give a summary and then give a list of things
|
|
for 5.0.</p>
|
|
|
|
<p><strong class="speaker">jhb</strong> : The big thing for 5.0 is to
|
|
get the network stack out from under Giant.</p>
|
|
|
|
<p><strong class="speaker">jhb</strong> : Jeffrey Hsu and Jennifer Yang
|
|
were here to talk about this. They have the PCBs checked in now.</p>
|
|
|
|
<p><strong class="speaker">jennifer</strong> : Interface Queues and SynCache
|
|
might be done.</p>
|
|
</div>
|
|
|
|
<p>The remaining chunks of the network code are:</p>
|
|
|
|
<ul>
|
|
<li>Routing Table Locking</li>
|
|
<li>Socket Buffers</li>
|
|
<li>ifa structures</li>
|
|
<li>struct ifnet</li>
|
|
<li>locking ipfw and dummynet</li>
|
|
<li>other (non IPv4) protocols</li>
|
|
<li>Netgraph</li>
|
|
</ul>
|
|
|
|
<div class="discussion">
|
|
|
|
<p><strong class="speaker">jhb</strong> : Aside from network the newbus
|
|
locking needs to be done (Warner Losh) and also CAM stuff. No known
|
|
status on CAM. Perhaps CAM is not needed for 5.0</p>
|
|
|
|
<p><strong class="speaker">jhb</strong> : Disk drive interrupts? Would
|
|
help performance. Going to talk to Poul Henning-Kamp</p>
|
|
|
|
<p><strong class="speaker">jhb</strong> : Alan Cox is working on the VM
|
|
system. Working based on the old Mach stuff. Objective for 5.0 is to
|
|
get zero fill and execute on write to work without Giant. In future
|
|
he wants to look at locking down pmap() functions.</p>
|
|
|
|
<p><strong class="speaker">jhb</strong> : Still some stability issues.
|
|
UMA breaks some assumptions. For instance sockets assume that once
|
|
memory is a socket its a socket forever, this is no longer true.</p>
|
|
|
|
<p><strong class="speaker">jhb</strong> : Talked to Mike Smith about
|
|
5.0 and have decided to stop adding features so that we can start
|
|
clean up 5.0 and make it a real release. This might require hacks.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : For example in the UMA case
|
|
there could be a flag to just say "don't reclaim this zone" -- this
|
|
would help with issues such as the socket code assuming memory is type
|
|
stable.</p>
|
|
|
|
<p>Over to Alan Cox on the VM system.</p>
|
|
|
|
<p><strong class="speaker">alc</strong> : Nothing to say.</p>
|
|
|
|
<p><strong class="speaker">bmilekic</strong> : As much as I might get hated
|
|
for this. Will preemption stuff go in by 5.0?</p>
|
|
|
|
<p><strong class="speaker">jhb</strong> :No, that's a 6.0 thing. There
|
|
are things to do first.</p>
|
|
|
|
<p><strong class="speaker">unknown</strong> : Could this come in in
|
|
the life time of 5.? 5.1?</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : This is a release issue really.</p>
|
|
|
|
<p><strong class="speaker">jhb</strong> : Yes, the kernel is pre-emptive.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : Perhaps we should talk about
|
|
is performance goals? What are the comparisons to make? Perhaps head
|
|
of 4 with head of 5. We'll see a mix.</p>
|
|
|
|
<p><strong class="speaker">jhb</strong> : I need to run benchmarks.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : In terms of SMP features when
|
|
will VM be ready to be measured? I can't put a date on it.</p>
|
|
|
|
<p><strong class="speaker">alc</strong> : I think I told John was in
|
|
time for release. I'm already doing performance testing so we've
|
|
already started.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : We'll pick a date to start
|
|
doing measurements. Perhaps 2 or 3 weeks from now.</p>
|
|
|
|
<p><strong class="speaker">alc</strong> : My guess is the the locking
|
|
pmap is going to take some time to shake out. On the other hand the
|
|
next major module we should be working on is machine dependent level.
|
|
Last we should try approaching the vmobject level. I'll start
|
|
worrying about performance in the near term.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : Will threading improve
|
|
latency or throughput for networking?</p>
|
|
|
|
<p><strong class="speaker">bmilekic</strong> : I would like if we could
|
|
actually start before.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : Do you have a timeline for
|
|
the interrupt threading stuff?</p>
|
|
|
|
<p><strong class="speaker">bmilekic</strong> : I finished some things last
|
|
night but there are still issues. In a couple of weeks it should be
|
|
ready for first commit.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : Informally beginning to
|
|
measure performance now. What are the right sets of tests? Need to
|
|
discuss on -arch.</p>
|
|
|
|
<p><strong class="speaker">alc</strong> : It would be nice to have that
|
|
committed to the tools directory.</p>
|
|
|
|
<p><strong class="speaker">jhb</strong> : The statistics analysis
|
|
package are we using.</p>
|
|
|
|
<p><strong class="speaker">bmilekic</strong> : I have some good success with
|
|
netpipe for overall measurement.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : Need to be using consistent
|
|
compilers because of the compiler change. Also all our debugging
|
|
stuff will slow down the benchmarking.</p>
|
|
</div>
|
|
|
|
<p>Benchmark Ideas</p>
|
|
<ul>
|
|
<li>chroot of 4.6 area for testing</li>
|
|
<li>buildworld</li>
|
|
<li>build X11R4 w/gcc 2.95</li>
|
|
<li>netpipe on loopback</li>
|
|
<li>end to end testing on on gigE cards
|
|
(throughput,connections/sec)</li>
|
|
<li>thread stuff like mySQL</li>
|
|
<li>Kirk's FS benchmarks</li>
|
|
<li>NFS Tests (nfsstone)</li>
|
|
<li>Sleepycat DB tests?</li>
|
|
</ul>
|
|
|
|
<p>Tests to be run on:</p>
|
|
<ul>
|
|
<li>4.6-RELEASE</li>
|
|
<li>5.0-DP1</li>
|
|
<li>5.0-DP2</li>
|
|
<li>5-CURRENT</li>
|
|
<li>4-STABLE</li>
|
|
</ul>
|
|
|
|
<p>Targets:</p>
|
|
<ul>
|
|
<li>alpha, i386</li>
|
|
<li>UP, 2/4-way SMP, SMP with one processor</li>
|
|
<li>low/high memory</li>
|
|
<li>slow/fast CPU</li>
|
|
</ul>
|
|
|
|
<div class="discussion">
|
|
|
|
<p><strong class="speaker">dillon</strong> : Debug stuff on 5.0. I think
|
|
it might be reasonable then to take the space hit and always have the
|
|
debugging in but turn it on and off with sysctl.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : We should commit an optimized
|
|
kernel configuration and benchmarking guidelines to the tree as
|
|
well.</p>
|
|
</div>
|
|
|
|
&break;
|
|
|
|
<div class="discussion">
|
|
|
|
<p><strong class="speaker">rwatson</strong> : I think we should continue
|
|
the performance discussion. We want to accomplish a couple of things.
|
|
One is stability measurement. What are the things we need to be
|
|
measuring? What is our definition of useful?</p>
|
|
|
|
<p><strong class="speaker">hsu</strong> : End to end measurement
|
|
with gigabit cards. For latency test connections per second. Can use
|
|
ttcp or netbench in ports.</p>
|
|
|
|
<p><strong class="speaker">gnn</strong> : need to make sure we run
|
|
against all of 4.6</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : Need to really have 3 tests.
|
|
4.6 (forever) 4.x (following updates) and -CURRENT.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : There are other dimensions.
|
|
Degree of parallelism for instance. We might see degradation in uni
|
|
but get good stuff in multi case.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : Test for impact of KSE
|
|
complications as well.</p>
|
|
|
|
<p><strong class="speaker">alfred</strong> : I think as the results come
|
|
through people should not be too worried about it. Perhaps we should
|
|
benchmark database type stuff as well. Need to do something
|
|
comprehensive.</p>
|
|
|
|
<p><strong class="speaker">obrien</strong> : What does the test matrix
|
|
look like? Different architectures and different numbers of
|
|
processors.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : Can we make a multi-processor
|
|
run uni-processor.</p>
|
|
|
|
<p><strong class="speaker">alfred</strong> : Run queue and scheduler stuff?</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : Will talk to Alfred.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : Is scalability testing
|
|
important?</p>
|
|
|
|
<p><strong class="speaker">obrienM</strong> : NFS testing.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : What about UI testing?</p>
|
|
|
|
<p><strong class="speaker">hsu</strong> : x11perf is the way to do that.</p>
|
|
|
|
<p><strong class="speaker">dillon</strong> : Currently we have a directory
|
|
for regression tests, should we do one for performance tests?</p>
|
|
|
|
<p><strong class="speaker">gnn</strong> : talk to sleepycat for DB
|
|
tests, see if they have some</p>
|
|
|
|
<p><strong class="speaker">alfred</strong> : Really nice to tests DB
|
|
applications that are heavily thread dependent.</p>
|
|
|
|
<p><strong class="speaker">hsu</strong> :Apache 2 has threads.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : What about commercial folks?
|
|
What do you do.</p>
|
|
|
|
<p><strong class="speaker">ps</strong> : Normally what we end
|
|
up doing is using the snapshot on some machines and see if the bugs
|
|
are out. There is no performance testing really.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : Again, what about performance?</p>
|
|
|
|
<p><strong class="speaker">ps</strong> : We've really never had
|
|
one. It's more just bugs. We've just never found the performance to
|
|
be a problem.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : We need to create a forum for
|
|
talking about performance. We need reproducible test cases.</p>
|
|
|
|
<p><strong class="speaker">ps</strong> : There's also other
|
|
things. We've been doing lots of looking at this. FreeBSD gets
|
|
kicked down by attacks for instance. We have a lot of tools to get to
|
|
the project though.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : I will set up the mailing
|
|
list.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="topic">
|
|
<hr/>
|
|
<a name="hw"></a>
|
|
<h2>New Hardware Architectures</h2>
|
|
|
|
<h3>Alpha</h3>
|
|
|
|
<div class="discussion">
|
|
|
|
<p><strong class="speaker">jhb</strong> : Questions about alpha?</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : KSE on alpha?</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : We have patches so it
|
|
compiles and runs non-KSE programs. You can have the patched version
|
|
of the alpha kernel up and running though.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : Is the task owned of making
|
|
this work on Alpha?</p>
|
|
|
|
</div>
|
|
|
|
<h3>IA64</h3>
|
|
|
|
<div class="discussion">
|
|
|
|
<p><strong class="speaker">dfr</strong> : It works as far as I get to
|
|
use it. It's not used in production right now.</p>
|
|
|
|
<p><strong class="speaker">ps</strong> : Intel shipped me a quad
|
|
processor IA64 board. (McKinley is the name of the board).</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : What does it need for 5.0?</p>
|
|
|
|
<p><strong class="speaker">dfr</strong> : It works, it works for SMP.
|
|
Self hosts, build worlds. sysinstall compiles but needs more kicking
|
|
to work.</p>
|
|
|
|
<p><strong class="speaker">ps</strong> : Intel wants us to ship
|
|
a CD.</p>
|
|
|
|
<p><strong class="speaker">dfr</strong> : There is no thread support
|
|
right now (threading library needs to move to get/setcontext rather
|
|
than longjmp).</p>
|
|
|
|
<p><strong class="speaker">dfr</strong> : Need to move every driver to
|
|
use BUS DMA for large memory machines to get bounce buffers.</p>
|
|
|
|
<p><strong class="speaker">jhb</strong> : PHK is working on using a new
|
|
libwhisk so that sysinstall et al work on all systems.</p>
|
|
|
|
</div>
|
|
|
|
<h3>Sparc64</h3>
|
|
|
|
<div class="discussion">
|
|
|
|
<p><strong class="speaker">jake</strong> : Take control of KSE stuff
|
|
on Sparc 64.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : Do we have a Sparc 64 in the
|
|
cluster?</p>
|
|
|
|
<p><strong class="speaker">jake</strong> : It's not in the cluster
|
|
yet. It's a serial cluster issue.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : Package building on S64?</p>
|
|
|
|
<p><strong class="speaker">jake</strong> : Perhaps a bunch of Ultra
|
|
60s for a package build.</p>
|
|
|
|
<p><strong class="speaker">obrien</strong> : 1500 build right now?</p>
|
|
|
|
<p><strong class="speaker">jake</strong> : Yes, but a lot of the
|
|
same bug in packages are broken.</p>
|
|
|
|
<p><strong class="speaker">jhb</strong> : Timeline for X?</p>
|
|
|
|
<p><strong class="speaker">jake</strong> : Not really.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : In terms of 5.0 how
|
|
comfortable are you?</p>
|
|
|
|
<p><strong class="speaker">jake</strong> : sysinstall is the only problem.</p>
|
|
</div>
|
|
|
|
<h3>PowerPC</h3>
|
|
|
|
<div class="discussion">
|
|
|
|
<p><strong class="speaker">benno</strong> : I got it up to
|
|
execing a fake init in the simulator and printing "hello world".
|
|
Trying to work with real hardware. I now have some semblance of
|
|
busdma and am working on other stuff. GEM on iMac is in an embryonic
|
|
state. Should get to NFS mount in a few weeks.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : How do you feel about your
|
|
timeline?</p>
|
|
|
|
<p><strong class="speaker">benno</strong> : I'm not sure we'll have
|
|
something fully workable for 5.0.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : You're not at the point yet
|
|
on working on KSE are you?</p>
|
|
|
|
<p><strong class="speaker">benno</strong> : No, need a useful system
|
|
first.</p>
|
|
|
|
</div>
|
|
|
|
<h3>AMD64</h3>
|
|
|
|
<div class="discussion">
|
|
|
|
<p><strong class="speaker">rwatson</strong> : I know that we're having
|
|
simulator problems.</p>
|
|
|
|
<p><strong class="speaker">obrien</strong> : The issues are about legal
|
|
and NDA. AMD decided on <a href="http://www.freebsdmall.com">FreeBSD
|
|
Mall</a> as the NDA person. I have not had a working simulator since
|
|
September.</p>
|
|
|
|
<p><strong class="speaker">ps</strong> : I can make that happen, as
|
|
well as real hardware.</p>
|
|
|
|
<p><strong class="speaker">obrien</strong> :I've got a cross tool chain in
|
|
the tree. I have some untested pmap stuff. Hardware has been
|
|
available for a month or so. We could boot FreeBSD 4.6 today if only
|
|
we had hardware.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : What do you think about 5.0?
|
|
Should we discuss that at another date?</p>
|
|
|
|
</div>
|
|
|
|
<h3>MIPs</h3>
|
|
|
|
<div class="discussion">
|
|
|
|
<p><strong class="speaker">unknown</strong> :Juniper offered.</p>
|
|
|
|
<p><strong class="speaker">obrien</strong> : But we have no hardware.</p>
|
|
|
|
<p><strong class="speaker">unknown</strong> :Juniper thinks it's OK but
|
|
doesn't want to have it rot in the tree.</p>
|
|
|
|
<p><strong class="speaker">brooks</strong> : I have a line on a company
|
|
that does compact PCI with R6Ks.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : We're waiting for someone to
|
|
turn up.</p>
|
|
|
|
</div>
|
|
</div>
|
|
|
|
<hr/>
|
|
LUNCH
|
|
<hr/>
|
|
|
|
<div class="topic">
|
|
<hr/>
|
|
<a name="trust"></a>
|
|
<h2>Trusted BSD</h2>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : Malc framework is what is of
|
|
interest today.</p>
|
|
|
|
<em>See Slides from Robert</em>
|
|
|
|
<div class="discussion">
|
|
|
|
<p><strong class="speaker">julian</strong> : Are the labels the same on
|
|
all structures?</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : You can modify this but there
|
|
are issues with memory: is the space needed for a label too large to
|
|
add to an mbuf header, for example? The label is small, but there
|
|
area lot of them?</p>
|
|
|
|
<p><strong class="speaker">bmilekic</strong> : When you're freeing the mbuf
|
|
do you write the label data?</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : We blank it when we free it.</p>
|
|
|
|
<p><strong class="speaker">bmilekic</strong> : I do not think the 36 bytes
|
|
in the mbuf header is a problem.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : I'm more interested in the
|
|
"why" than the how.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : A lot of people are
|
|
interested in this. Some of the things that do interest a lot of
|
|
people are things like doing on the fly security for a web server.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : Is there a black hatted TLA
|
|
interested?</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : Yes and several gov'ts. As
|
|
well as plenty of financial folks.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : There's a lot of userland
|
|
stuff that's not done yet.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="topic">
|
|
<hr/>
|
|
<a name="releng"></a>
|
|
<h2>Release Engineering</h2>
|
|
|
|
<p><strong class="speaker">murray</strong> : Shows a slide of releases.
|
|
4.6 is ready to go but having issues with ISO images. DP1, a lot of
|
|
goals were met. 1000 packages were building on -CURRENT to get DP1
|
|
out. Polished 4.2. We need to start making decisions on 5.0.
|
|
November is still the date we're shooting for. We're going to do a
|
|
4.7 and a 4.8. DP3?</p>
|
|
|
|
<p>***GET SLIDE FROM MURRAY***</p>
|
|
|
|
<div class="discussion">
|
|
|
|
<p><strong class="speaker">murray</strong> : Release engineering area of
|
|
the web site www.FreeBSD.org/releng. For DP2 question about p4 or
|
|
CVS? Will probably use p4 for DP2 as well. USB subsystem? Perl
|
|
removal? KSE?</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : KSE should be able to run
|
|
simple tests.</p>
|
|
|
|
<p><strong class="speaker">obrien</strong> : Is whatever you have
|
|
committed by DP2 be the same as the release.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : It will be a subset.</p>
|
|
|
|
<p><strong class="speaker">murray</strong> : What will the status be of
|
|
KSE in userland for 5.0?</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : Can't answer that right
|
|
now. We're not removing the old libraries. The userland work will
|
|
happen between DP2 and release. The next step is MP as well as
|
|
UP.</p>
|
|
|
|
<p><strong class="speaker">obrien</strong> : Are we heading for a release?</p>
|
|
|
|
<p><strong class="speaker">murray</strong> : yes.</p>
|
|
|
|
<p><strong class="speaker">obrien</strong> : Then we have to stop having
|
|
major commits.</p>
|
|
|
|
<p><strong class="speaker">murray</strong> : Yes, the discussion today is
|
|
what are the major must have features.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : We need to decide if there
|
|
are major upcoming problems and reduce risk on things like KSE.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : That's why I want to get milestone 3
|
|
in now.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : Do you think that KSE related
|
|
changes from later milestones are going to be isolated to KSE or
|
|
pervasive?</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : Hard to say. My guess is
|
|
that milestone 4 stuff should be less pervasive.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : What happens if KSE just
|
|
doesn't work?</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : Well it does work, the
|
|
patches work, it's a question of risk. We need to check on new
|
|
things, like locking two threads in the same process.</p>
|
|
|
|
<p><strong class="speaker">dillon</strong> : KSEs only become fragile when
|
|
pthread uses them. That's the turning point.</p>
|
|
|
|
<p><strong class="speaker">obrien</strong> : I'd like the rules for the
|
|
rest of the summer, I hope we'll talk about that.</p>
|
|
|
|
<p><strong class="speaker">murray</strong> : Earlier is better.</p>
|
|
|
|
<p><strong class="speaker">mini</strong> : I think the cutoff point for
|
|
KSE might be milestone 3.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : It's the kind of thing where
|
|
if we need to back out we can.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : If you're not going to run
|
|
KSEs then you're OK.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : I think it's low risk. Let's
|
|
avoid the risk is the message.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : The next DP2 (where we'd like
|
|
milestone 4).</p>
|
|
|
|
<p><strong class="speaker">alfred</strong> : We really need KSE so all
|
|
this concern about stuff that no one really uses is not a big deal.
|
|
People just need to play catch up. We have performance problems and
|
|
we need to solve those.</p>
|
|
|
|
<p><strong class="speaker">obrien</strong> : We quickly need to figure out
|
|
our policy on multiple archs.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : I briefly want to respond to
|
|
Alfred. We have asserted that KSE will be experimental. It will be
|
|
in and 5.0 will go out but there might be issues.</p>
|
|
|
|
<p><strong class="speaker">jhb</strong> : Realistically for the network
|
|
stack is that IPv4 sockets will not be giant. But this is only in the
|
|
network stack world. Several people are working on it.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : The GEOM stuff will be
|
|
enabled by default in 5.0. Sparc depends on it. I do not know what
|
|
the impediments are to that though.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : The kernel stuff is there but
|
|
the user space is not. It can't become the default until everything
|
|
is there.</p>
|
|
|
|
<p><strong class="speaker">warner</strong> : What level of control are you
|
|
going to exercise over the tree in the coming months?</p>
|
|
|
|
<p><strong class="speaker">murray</strong> : You're going to see more
|
|
level of control but we expect the requests to be reasonable. It's a
|
|
very open process.</p>
|
|
|
|
<p><strong class="speaker">jhb</strong> : How are we going to address the
|
|
5/6 split?</p>
|
|
|
|
<p><strong class="speaker">murray</strong> : Carefully is all I can
|
|
say.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : For 5. 0 we need to have a
|
|
more informed decision. The release engineers will be trying to
|
|
reduce the number of large code changes more as time goes by. We
|
|
don't have to wait for 5.x to be perfectly stable before we branch.</p>
|
|
|
|
<p><strong class="speaker">murray</strong> : Let's move it to more general
|
|
discussion of DP2? Specific technologies.</p>
|
|
|
|
<p><strong class="speaker">bmilekic</strong> : Is there a strategy to lock
|
|
other protocols that are not locked down onw?</p>
|
|
|
|
<p><strong class="speaker">obrien</strong> : How much more do we need to
|
|
do before 5.0?</p>
|
|
|
|
<p><strong class="speaker">jhb</strong> : Bug fixing is what we're doing.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : The answer on the network
|
|
stack. We need to choose a strategy on how to handle the other
|
|
protocols.</p>
|
|
|
|
<p><strong class="speaker">obrien</strong> : The crux is that socket
|
|
locking must be in 5.0.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : There are 2 or 3 problems.
|
|
Routing code is a problem. See earlier discussions.</p>
|
|
|
|
<p><strong class="speaker">dfr</strong> : RCng is essentially done.
|
|
What it needs is testers.</p>
|
|
|
|
<p><strong class="speaker">alfred</strong> : What about libh (I think libh
|
|
is wrong but this is what I heard)?</p>
|
|
|
|
<p><strong class="speaker">jhb</strong> : It's very far along but not a
|
|
5.0 thing.</p>
|
|
|
|
<p><strong class="speaker">warner</strong> : Problems with interrupt
|
|
routing in ACPI?</p>
|
|
|
|
<p><strong class="speaker">takawata</strong> : Cannot handle PCI<->PCI
|
|
interrupt routing. Many 802.11x have this problem.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : Is it a problem from Intel?</p>
|
|
|
|
<p><strong class="speaker">takawata</strong> : This is not an Intel
|
|
problem but a problem on our side. PCI<->PCI routing code should be
|
|
added. New code is necessary.</p>
|
|
|
|
<pre>
|
|
Whiteboard
|
|
|
|
UFS2 rcNG KSE M3 CAM SMPng
|
|
|
|
GEOM TrustedBSD Malc BusDMA Newbus SMPng
|
|
|
|
C++ Cardbus libwhisk/sysinstall KOBJ? (no!)
|
|
sparc64
|
|
|
|
Perl Removal ACPI Alpha SMP Stability Pkgs for
|
|
sparc64, IA64
|
|
|
|
devd PCI intr route document hints release docs
|
|
for new
|
|
platform
|
|
</pre>
|
|
|
|
<p><strong class="speaker">unknown</strong> : Firewire?</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : What hardware shipping on
|
|
IA64?</p>
|
|
|
|
<p><strong class="speaker">dfr</strong> : Intel stuff</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : What about on Sparc64?</p>
|
|
|
|
<p><strong class="speaker">obrien</strong> : Very limited (hme...)</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : KOBJ extensions discussed at
|
|
BSDCon?</p>
|
|
|
|
<p><strong class="speaker">warner</strong> : Not sure, probably not for
|
|
5.0. Pervasive, so no.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : How broken is C++?</p>
|
|
|
|
<p><strong class="speaker">obrien</strong> : Only on sparc64. Don't
|
|
really know yet, but it's probably a library issue. The compiler is a
|
|
pre-release snapshot. The diffs are now getting large from May 5 to
|
|
now. We should attempt to be as far along this gcc branch as possible
|
|
come release.</p>
|
|
</div>
|
|
</div>
|
|
|
|
&break;
|
|
|
|
<div class="topic">
|
|
<hr/>
|
|
<a name="rc"></a>
|
|
<h2>rc.d</h2>
|
|
</div>
|
|
|
|
<div class="discussion">
|
|
|
|
<p><strong class="speaker">gordon</strong> : Talking about rc.d stuff.
|
|
Import from NetBSD. Right now we have patches out there that are
|
|
translated from the current boot order. It's in perforce. After the
|
|
conference it will go into the mainline. Single toggle for
|
|
booting.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : How in sync are the bits in
|
|
the new stuff with the old stuff.</p>
|
|
|
|
<p><strong class="speaker">gordon</strong> : Last patch is from June 3rd,
|
|
but it's tracking closely.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : What is the schedule for
|
|
committing to the main tree.</p>
|
|
|
|
<p><strong class="speaker">gordon</strong> : We have large patches so
|
|
we're going to re-import from NetBSD.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : How about you have it done by
|
|
July 1?</p>
|
|
|
|
<p><strong class="speaker">gordon</strong> : We could probably do that.
|
|
Definitely want to be in DP2.</p>
|
|
|
|
<p><strong class="speaker">gshapiro</strong> : How long will we keep the old
|
|
stuff for?</p>
|
|
|
|
<p><strong class="speaker">gordon</strong> : We'll keep them both in for a
|
|
while. Not more than 1.5 months though.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : Have you had a look at all at
|
|
the Mac OS/X startup code?</p>
|
|
|
|
<p><strong class="speaker">gordon</strong> : No.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : Do you deal with dependencies?</p>
|
|
|
|
<p><strong class="speaker">gordon</strong> : There is meta data in each
|
|
script that says what needs what. There is a program that orders
|
|
everything correctly.</p>
|
|
|
|
<p><strong class="speaker">unknown</strong> : How does this effect the rc
|
|
script for ports install?</p>
|
|
|
|
<p><strong class="speaker">gordon</strong> : We could make this available
|
|
to ports but won't on the first version.</p>
|
|
|
|
<p><strong class="speaker">alfred</strong> : Can I recommend that you
|
|
recommend this to ports?</p>
|
|
|
|
<p><strong class="speaker">gordon</strong> : Yes, the problem is that we
|
|
have so many ports.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : The reason for this is for
|
|
rebundlers of FreeBSD in their environments. We don't have to have it
|
|
for DP2 but it should be an ultimate goal. We might need to have a
|
|
policy statement on this. That at date X all ports must use the new
|
|
system.</p>
|
|
|
|
</div>
|
|
|
|
<div class="topic">
|
|
<hr/>
|
|
<a name="open"></a>
|
|
<h2>Other Issues</h2>
|
|
</div>
|
|
|
|
<div class="discussion">
|
|
|
|
<p><strong class="speaker">sam</strong> : I've been working on hardware
|
|
crypto. I'm looking for consensus on getting hardware crypto in the
|
|
kernel. This will not happen in 5.0.</p>
|
|
|
|
<h3>Syscall vector change for 64bits</h3>
|
|
|
|
|
|
<p><strong class="speaker">dillon</strong> : Two ways to go. Need to
|
|
create a new syscall vector. The other is to do a 1 off replacement.
|
|
Prefer the former.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : Perhaps we need to create a
|
|
FreeBSD 5 syscall vector. Could be a new ABI.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : Aren't there enough other
|
|
numbers?</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : That's one way to look at it
|
|
and other platforms have done that? Is that too heavy weight?</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : It sounds that way to me.
|
|
You end up having to replicate the old ones into the new one.</p>
|
|
|
|
<p><strong class="speaker">dillon</strong> : The issue is about pollution.</p>
|
|
|
|
<p><strong class="speaker">dfr</strong> : Seems like too much work for 5.x</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : It's more work. There are
|
|
now two places. Why not talk to OpenBSD?</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : Should there be a BSD alfredI?
|
|
Tough to do across projects.</p>
|
|
|
|
<p><strong class="speaker">obrien</strong> : Who here is going to see that
|
|
through? We have not talked to NetBSD about even SMP.</p>
|
|
|
|
<p><strong class="speaker">alfred</strong> : Does changing the syscall
|
|
table allow us to do clean up?</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : We could do that without
|
|
doing 64bit syscall table.</p>
|
|
|
|
<h3>5.x ABI stability</h3>
|
|
|
|
|
|
<p><strong class="speaker">rwatson</strong> : There are new functions in
|
|
5.x. At what point do we stop changing?</p>
|
|
|
|
<p><strong class="speaker">dfr</strong> : When people start really using it.</p>
|
|
<p><strong class="speaker">rwatson</strong> : How do we tell? How did
|
|
Solaris do it?</p>
|
|
|
|
<p><strong class="speaker">Everyone</strong> : No one knows.</p>
|
|
|
|
<p><strong class="speaker">dfr</strong> : It's too hard to add a
|
|
syscall vector. Library issues are a problem.</p>
|
|
|
|
<p><strong class="speaker">obrien</strong> : We can use ELF to handle that.</p>
|
|
|
|
<p><strong class="speaker">dfr</strong> : Let's just add 20 new
|
|
syscalls instead of adding new work that we don't really really need.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : Punt on lack of time to do
|
|
this.</p>
|
|
|
|
<p><strong class="speaker">dillon</strong> : I see obrien's point with the
|
|
libraries but I have done this with time_t at 64 bits.</p>
|
|
|
|
<h3>devd</h3>
|
|
|
|
|
|
<p><strong class="speaker">rwatson</strong> : The devd stuff was to
|
|
integrate cardbus, newbus, etc.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : To monitor requests to mount
|
|
or create new devices.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : Is this a 5.0 requirement?
|
|
Is there anyone to do this?</p>
|
|
|
|
<!-- Which Gordon was this ? -->
|
|
<p><strong class="speaker">gordon (from IRC)</strong> : PHK has patches
|
|
that make having devd unnecessary.</p>
|
|
|
|
<p><strong class="speaker">brooks</strong> : Need something that does what
|
|
pccardd did.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : Need to be able to do this
|
|
through a file.</p>
|
|
|
|
<p><strong class="speaker">warner</strong> : (from IRC): That's a 6.0
|
|
feature.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : It would not be a large step
|
|
to put something in the middle to handle this.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : Sometime in the 5 lifetime we
|
|
need this.</p>
|
|
|
|
<p><strong class="speaker">warner</strong> : There is no way to monitor
|
|
events in newbus but it would be easy to add.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : I'm not sure I understood you
|
|
correctly.</p>
|
|
|
|
<p><strong class="speaker">warner</strong> : What happens now in a PCI is
|
|
that it makes a call to pci_get_devid() and the driver would say "yes
|
|
I am " or "no I'm not" so you'd have to change each of the busses to
|
|
do this but that's not too tough because we have a small # of
|
|
busses.</p>
|
|
|
|
<p><strong class="speaker">jhb</strong> : Mike Smith gave us an
|
|
informal tour of OS/X. OS/X uses XML to do this. They have the DEVID
|
|
in XML.</p>
|
|
|
|
<p><strong class="speaker">brooks</strong> : I looked at some PCI drivers
|
|
and some work that way but some don't.</p>
|
|
|
|
<p><strong class="speaker">julian</strong> : It seems to me we need to not
|
|
have to modify every single driver. If you've got a device that's not
|
|
supported you ask all drivers. At the point when you run out you make
|
|
an outcall. The outcall returns does a substitution.</p>
|
|
|
|
<p><strong class="speaker">rwatson</strong> : Time up, time to wrap up.</p>
|
|
</div>
|
|
|
|
</body>
|
|
</html>
|
|
|