Attachment 24921 Details for Bug 42512 – file.diff

[patch] file.diff

file.diff (text/plain), 54.32 KB, created by dominic_marks on 2002-09-07 19:50:02 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: dominic_marks

Created: 2002-09-07 19:50:02 UTC

Size: 54.32 KB

patch

obsolete

>Index: usenix-devsummit.sgml
>===================================================================
>RCS file: /media/cvs/freebsd/www/en/events/2002/usenix-devsummit.sgml,v
>retrieving revision 1.4
>diff -u -3 -p -r1.4 usenix-devsummit.sgml
>--- usenix-devsummit.sgml	4 Sep 2002 14:41:53 -0000	1.4
>+++ usenix-devsummit.sgml	4 Sep 2002 20:00:02 -0000
>@@ -43,44 +43,52 @@ Stokely</a>.
> <li><a href="#open">Open Discussion</a></li>
> </ul>
> 
>-NOTE: As usual I missed some names, please add those I missed.
>+NOTE: As usual I missed some names, please add those I missed. During
>+ the discussion names have been abbreviated, for committers their
>+ FreeBSD.org username has been used, for non committers the initials
>+ are used.
> 
> <h2>Attending:</h2>
> 
>-In person:
>+Committers In Person:
>+<ul>
>+ <li>Robert Watson (rwatson)</li>
>+ <li>Julian Elischer (julian)</li>
>+ <li>John Baldwin (jhb)</li>
>+ <li>Matt Dillon (dillon)</li>
>+ <li>Warner Losh (warner)</li>
>+ <li>David O'Brien (obrien)</li>
>+ <li>Jeffery 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>
>+</ul>
>+
>+Also In Person:
> <ul>
>- <li>Robert Watson (RW)</li>
>- <li>Julian Elischer(JE)</li>
>- <li>John Baldwin(JB)</li>
>- <li>Matt Dillon (MD)</li>
>- <li>Warner Losh (WL)</li>
>- <li>David O'Brian (DO)</li>
>- <li>Jeffery Xu (JX)</li>
>- <li>Jennifer Ying (JY)</li>
>- <li>Bosko Milekic (BM)</li>
>- <li>Alfred Perlstein (AP)</li>
>- <li>Doug Rabson (DR)</li>
>- <li>Paul Saab (PS)</li>
>- <li>Brooks Davis (BD)</li>
>- <li>Murray Stokely (MS)</li>
>- <li>Jonathan Mini (JM)</li>
>- <li>Watanabe ???</li>
>- <li>Gordon Tetlow (GT)</li>
>- <li>Gregory Schapiro (GS)</li>
>- <li>Sam Leffler (SL)</li>
>- <li>Bruce Mah</li>
> <li>George Neville-Neil (gnn)</li>
>- <li>Unknown (??)</li>
>+ 
> </ul>
> 
> On The Phone:
> <ul>
>- <li>Alan Cox (AC)</li>
>+ <li>Alan Cox (alc)</li>
> </ul>
> 
> Via webcast:
> 
>-??
>+Many people listened in via the stream and chatted on IRC to one
>+ another while the discussion took place.
> 
> The meeting followed a format where each section was led by an
> individual and then a discussion ensued. Not all of the discussion
>@@ -125,75 +133,75 @@ perforce and people have to patch it. 
> <div class="discussion">
> 
>-RW : What about userland?
>+rwatson : What about userland?
> 
>-JE : It can run different threads
>+julian : 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?
> 
>-RW : Putting async I/O into such a
>+rwatson : Putting async I/O into such a
> thing would make sense.
> 
>-JE : The library would not care
>+julian : The library would not care
> who was accessing it.
> 
>-RW : For instance libc could be
>+rwatson : For instance libc could be
> threaded or not.
> 
>-JE : That would be interesting. I
>+julian : That would be interesting. I
> don't know if the two interfaces are incompatible.
> 
>-JB : X does this.
>+jhb : X does this.
> 
>-MD : It is very doable but you
>+dillon : 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.
> 
>-JE : If I do what I'm thinking of
>+julian : If I do what I'm thinking of
> doing then each lib will have its own KSE group.
> 
>-MD : stdio does not have to be
>+dillon : stdio does not have to be
> thread aware if you don't schedule preemptively. It all matters where
> it blocks.
> 
>-JE : Since you're a non-threaded
>+julian : Since you're a non-threaded
> program you don't know that.
> 
>-RW : If you're going to support
>+rwatson : If you're going to support
> that, libc has to support threads.
> 
>-RW : It sounds like some
>+rwatson : It sounds like some
> complexity goes away. Can we use 1 libc with has threading?
> 
>-JE : Do we want to go down this
>+julian : Do we want to go down this
> path?
> 
>-RW : Now or later?
>+rwatson : Now or later?
> 
>-JE : What do I design now to do
>+julian : What do I design now to do
> this?
> 
>-JB : For example libc_r does not
>+jhb : For example libc_r does not
> work with rfork.
> 
>-JE : The answer is that yes we
>+julian : The answer is that yes we
> should move forward. Tricky issues, signals...
> 
>-WL : Have people talked about
>+warner : Have people talked about
> pthread programs and cancellation points?
> 
>-JE : The pthreads library does not
>+julian : 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.
> 
>-JE : When a thread is scheduled
>+julian : When a thread is scheduled
> onto a KSE there is a mailbox that the userland thread scheduler
> updates.
> 
>-JE : Is there anyone else who has
>+julian : 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
>@@ -201,25 +209,25 @@ be able to patch it to -CURRENT. There 
> freefal there is a pointer there to a web page that explains how to
> CVSUP from source.
> 
>-RW : What about SMP locking for
>+rwatson : What about SMP locking for
> this?
> 
>-JE : Handled by the proc locking.
>+julian : Handled by the proc locking.
> Has not been tried on SMP machines yet.
> 
>-DO : What about on Sparc?
>+obrien : What about on Sparc?
> 
>-JE : You may need to stub things
>+julian : You may need to stub things
> out.
> 
>-JB : Is the paper on the web site?
>+jhb : Is the paper on the web site?
> 
>-JE : The updated copy has disappeared. 
>+julian : The updated copy has disappeared. 
> 
>-?? : What's the different between
>+unknown : What's the different between
> NetBSD and FreeBSD on this?
> 
>-JE : Logically not a tremendous
>+julian : 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
>@@ -231,10 +239,10 @@ end we ended up breaking up the proc str
> overwhelm the CPU when scheduling threads. This is the major
> difference.
> 
>-JE : I greatly admire the NetBSD
>+julian : I greatly admire the NetBSD
> way which is to take an idea and not dilute it.
> 
>-JE : Net is also putting a Solaris
>+julian : Net is also putting a Solaris
> compatible threads package on top of their scheduler activations in
> the Solaris ABI.
> </div>
>@@ -247,17 +255,17 @@ the Solaris ABI.
> 
> <div class="discussion">
> 
>-JB : Yesterday we talked about SMP
>+jhb : Yesterday we talked about SMP
> related things so I'll give a summary and then give a list of things
> for 5.0.
> 
>-JB : The big thing for 5.0 is to
>+jhb : The big thing for 5.0 is to
> get the network stack out from under Giant.
> 
>-JB : Jefferey Xu and Jennifer Ying
>+jhb : Jefferey Xu and Jennifer Ying
> were here to talk about this. They have the PCBs checked in now.
> 
>-JY : Interface Queues and SynCache
>+jennifer : Interface Queues and SynCache
> might be done.
> </div>
> 
>@@ -275,95 +283,95 @@ might be done.
> 
> <div class="discussion">
> 
>-JB : Aside from network the newbus
>+jhb : 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
> 
>-JB : Disk drive interrupts? Would
>+jhb : Disk drive interrupts? Would
> help performance. Going to talk to Poul Henning-Kamp
> 
>-JB : Alan Cox is working on the VM
>+jhb : 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.
> 
>-JB : Still some stability issues.
>+jhb : 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.
> 
>-JB : Talked to Mike Smith about
>+jhb : 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.
> 
>-RW : For example in the UMA case
>+rwatson : 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.
> 
>-Over to AC on the VM system. Nothing to say.
>+Over to alc on the VM system. Nothing to say.
> 
>-BM : As much as I might get hated
>+bmilekic : As much as I might get hated
> for this. Will preemption stuff go in by 5.0?
> 
>-JB :No, that's a 6.0 thing. There
>+jhb :No, that's a 6.0 thing. There
> are things to do first.
> 
>-??? Phone : Could this come in in
>+unknown : Could this come in in
> the life time of 5.? 5.1?
> 
>-RW : This is a release issue really.
>+rwatson : This is a release issue really.
> 
>-JB : Yes, the kernel is pre-emptive.
>+jhb : Yes, the kernel is pre-emptive.
> 
>-RW : Perhaps we should talk about
>+rwatson : 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.
> 
>-JB : I need to run benchmarks.
>+jhb : I need to run benchmarks.
> 
>-RW : In terms of SMP features when
>+rwatson : In terms of SMP features when
> will VM be ready to be measured? I can't put a date on it.
> 
>-AC : I think I told John was in
>+alc : I think I told John was in
> time for release. I'm already doing performance testing so we've
> already started.
> 
>-RW : We'll pick a date to start
>+rwatson : We'll pick a date to start
> doing measurements. Perhaps 2 or 3 weeks from now.
> 
>-AC : My guess is the the locking
>+alc : 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.
> 
>-RW : Will threading improve
>+rwatson : Will threading improve
> latency or throughput for networking?
> 
>-BM : I would like if we could
>+bmilekic : I would like if we could
> actually start before.
> 
>-RW : Do you have a timeline for
>+rwatson : Do you have a timeline for
> the interrupt threading stuff?
> 
>-BM : I finished some things last
>+bmilekic : I finished some things last
> night but there are still issues. In a couple of weeks it should be
> ready for first commit.
> 
>-RW : Informally beginning to
>+rwatson : Informally beginning to
> measure performance now. What are the right sets of tests? Need to
> discuss on -arch.
> 
>-AC : It would be nice to have that
>+alc : It would be nice to have that
> committed to the tools directory.
> 
>-JB : The statistics analysis
>+jhb : The statistics analysis
> package are we using.
> 
>-BM : I have some good success with
>+bmilekic : I have some good success with
> netpipe for overall measurement.
> 
>-RW : Need to be using consistent
>+rwatson : Need to be using consistent
> compilers because of the compiler change. Also all our debugging
> stuff will slow down the benchmarking.
> </div>
>@@ -401,11 +409,11 @@ stuff will slow down the benchmarking.</
> 
> <div class="discussion">
> 
>-MD : Debug stuff on 5.0. I think
>+dillon : 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.
> 
>-RW : We should commit an optimized
>+rwatson : We should commit an optimized
> kernel configuration and benchmarking guidlines to the tree as
> well.
> </div>
>@@ -414,85 +422,85 @@ well.
> 
> <div class="discussion">
> 
>-RW : I think we should continue
>+rwatson : 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?
> 
>-Jefferey : End to end measurement
>+hsu : End to end measurement
> with gigabit cards. For latency test connections per second. Can use
> ttcp or netbench in ports.
> 
> gnn : need to make sure we run
> against all of 4.6
> 
>-JE : Need to really have 3 tests.
>+julian : Need to really have 3 tests.
> 4.6 (forever) 4.x (following updates) and -CURRENT.
> 
>-RW : There are other dimensions.
>+rwatson : There are other dimensions.
> Degree of parallelism for instance. We might see degradation in uni
> but get good stuff in multi case.
> 
>-JE : Test for impact of KSE
>+julian : Test for impact of KSE
> complications as well.
> 
>-AP : I think as the results come
>+alfred : 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.
> 
>-DO : What does the test matrix
>+obrien : What does the test matrix
> look like? Different architectures and different numbers of
> processors.
> 
>-RW : Can we make a multi-processor
>+rwatson : Can we make a multi-processor
> run uni-procesor.
> 
>-AP : Run queue and scheduler stuff?
>+alfred : Run queue and scheduler stuff?
> 
>-JE : Will talk to Alfred.
>+julian : Will talk to Alfred.
> 
>-RW : Is scalability testing important?
>+rwatson : Is scalability testing important?
> 
>-DavidM : NFS testing.
>+obrienM : NFS testing.
> 
>-RW : What about UI testing?
>+rwatson : What about UI testing?
> 
>-JX : x11perf is the way to do that.
>+hsu : x11perf is the way to do that.
> 
>-MD : Currently we have a directory
>+dillon : Currently we have a directory
> for regression tests, should we do one for performance tests?
> 
> gnn : talk to sleepycat for DB
> tests, see if they have some
> 
>-AP : Really nice to tests DB
>+alfred : Really nice to tests DB
> applications that are heavily thread dependent.
> 
>-Jefferey :Apache 2 has threads.
>+hsu :Apache 2 has threads.
> 
>-RW : What about commercial folks?
>+rwatson : What about commercial folks?
> What do you do.
> 
>-Paul Saab : Normally what we end
>+ps : 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.
> 
>-RW : Again, what about performance?
>+rwatson : Again, what about performance?
> 
>-Paul Saab : We've really never had
>+ps : We've really never had
> one. It's more just bugs. We've just never found the performance to
> be a problem.
> 
>-RW : We need to create a forum for
>+rwatson : We need to create a forum for
> talking about performance. We need reproducible test cases.
> 
>-Paul Saab : There's also other
>+ps : 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.
> 
>-RW : I will set up the mailing list.
>+rwatson : I will set up the mailing list.
> </div>
> </div>
> 
>@@ -505,15 +513,15 @@ the project though.
> 
> <div class="discussion">
> 
>-JB : Questions about alpha?
>+jhb : Questions about alpha?
> 
>-RW : KSE on alpha?
>+rwatson : KSE on alpha?
> 
>-JE : We have patches so it
>+julian : 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.
> 
>-RW : Is the task owned of making
>+rwatson : Is the task owned of making
> this work on Alpha?
> 
> </div>
>@@ -522,29 +530,29 @@ this work on Alpha?
> 
> <div class="discussion">
> 
>-DR : It works as far as I get to
>+dfr : It works as far as I get to
> use it. It's not used in production right now.
> 
>-PS : Intel shipped me a quad
>+ps : Intel shipped me a quad
> processor IA64 board. (McKinley is the name of the board).
> 
>-RW : What does it need for 5.0?
>+rwatson : What does it need for 5.0?
> 
>-DR : It works, it works for SMP.
>+dfr : It works, it works for SMP.
> Self hosts, build worlds. sysinstall compiles but needs more kicking
> to work.
> 
>-Paul Saab : Intel wants us to ship
>+ps : Intel wants us to ship
> a CD.
> 
>-DR : There is no thread support
>+dfr : There is no thread support
> right now (threading library needs to move to get/setcontext rather
> than longjmp).
> 
>-DR : Need to move every driver to
>+dfr : Need to move every driver to
> use BUS DMA for large memory machines to get bounce buffers.
> 
>-JB : PHK is working on using a new
>+jhb : PHK is working on using a new
> libwhisk so that sysinstall et al work on all systems.
> 
> </div>
>@@ -553,99 +561,99 @@ libwhisk so that sysinstall et al work o
> 
> <div class="discussion">
> 
>-Jake B : Take control of KSE stuff
>+jake : Take control of KSE stuff
> on Sparc 64.
> 
>-RW : Do we have a Sparc 64 in the
>+rwatson : Do we have a Sparc 64 in the
> cluster?
> 
>-Jake B : It's not in the cluster
>+jake : It's not in the cluster
> yet. It's a serial cluster issue.
> 
>-RW : Package building on S64?
>+rwatson : Package building on S64?
> 
>-Jake B : Perhaps a bunch of Ultra
>+jake : Perhaps a bunch of Ultra
> 60s for a package build.
> 
>-David : 1500 build right now?
>+obrien : 1500 build right now?
> 
>-Jake B : Yes, but a lot of the
>+jake : Yes, but a lot of the
> same bug in packages are broken.
> 
>-JB : Timeline for X?
>+jhb : Timeline for X?
> 
>-Jake B : Not really.
>+jake : Not really.
> 
>-RW : In terms of 5.0 how
>+rwatson : In terms of 5.0 how
> comfortable are you?
> 
>-Jake B : sysinstall is the only problem.
>+jake : sysinstall is the only problem.
> </div>
> 
> <h3>PowerPC</h3>
> 
> <div class="discussion">
> 
>-Benno Rice : I got it up to
>+benno : 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.
> 
>-RW : How do you feel about your
>+rwatson : How do you feel about your
> timeline?
> 
>-Benno : I'm not sure we'll have
>+benno : I'm not sure we'll have
> something fully workable for 5.0.
> 
>-RW : You're not at the point yet
>+rwatson : You're not at the point yet
> on working on KSE are you?
> 
>-Benno : No, need a useful system
>+benno : No, need a useful system
> first.
> 
> </div>
> 
>-<h3>AMD64</h3>
>+<h3>Adillon64</h3>
> 
> <div class="discussion">
> 
>-RW : I know that we're having
>+rwatson : I know that we're having
> simulator problems.
> 
>-DO : The issues are about legal
>-and NDA. AMD decided on <a href="http://www.freebsdmall.com">FreeBSD
>+obrien : The issues are about legal
>+and NDA. Adillon decided on <a href="http://www.freebsdmall.com">FreeBSD
> Mall</a> as the NDA person. I have not had a working simulator since
> September.
> 
>-Paul : I can make that happen, as
>+ps : I can make that happen, as
> well as real hardware.
> 
>-DO :I've got a cross tool chain in
>+obrien :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.
> 
>-RW : What do you think about 5.0?
>+rwatson : What do you think about 5.0?
> Should we discuss that at another date?
> 
> </div>
> 
>-<h3>MIPS</h3>
>+<h3>MIps</h3>
> 
> <div class="discussion">
> 
>-??? :Juniper offered.
>+unknown :Juniper offered.
> 
>-DO : But we have no hardware.
>+obrien : But we have no hardware.
> 
>-??? :Juniper thinks it's OK but
>+unknown :Juniper thinks it's OK but
> doesn't want to have it rot in the tree.
> 
>-BD : I have a line on a company
>+brooks : I have a line on a company
> that does compact PCI with R6Ks.
> 
>-RW : We're waiting for someone to
>+rwatson : We're waiting for someone to
> turn up.
> 
> </div>
>@@ -660,43 +668,43 @@ LUNCH
> <a name="trust"></a>
> <h2>Trusted BSD</h2>
> 
>-RW : MAC framework is what is of
>+rwatson : Malc framework is what is of
> interest today.
> 
> See Slides from Robert
> 
> <div class="discussion">
> 
>-JE : Are the labels the same on
>+julian : Are the labels the same on
> all structures?
> 
>-RW : You can modify this but there
>+rwatson : 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?
> 
>-BM : When you're freeing the mbuf
>+bmilekic : When you're freeing the mbuf
> do you write the label data?
> 
>-RW : We blank it when we free it.
>+rwatson : We blank it when we free it.
> 
>-BM : I do not think the 36 bytes
>+bmilekic : I do not think the 36 bytes
> in the mbuf header is a problem.
> 
>-JE : I'm more interested in the
>+julian : I'm more interested in the
> "why" than the how.
> 
>-RW : A lot of people are
>+rwatson : 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.
> 
>-JE : Is there a black hatted TLA
>+julian : Is there a black hatted TLA
> interested?
> 
>-RW : Yes and several gov'ts. As
>+rwatson : Yes and several gov'ts. As
> well as plenty of financial folks.
> 
>-RW : There's a lot of userland
>+rwatson : There's a lot of userland
> stuff that's not done yet.
> </div>
> </div>
>@@ -706,171 +714,171 @@ stuff that's not done yet.
> <a name="releng"></a>
> <h2>Release Engineering</h2>
> 
>-MS : Shows a slide of releases.
>+murray : 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?
> 
>-***GET SLIDE FROM MURRAY***
>+***GET samIDE FROM MURRAY***
> 
> <div class="discussion">
> 
>-MS : Release engineering area of
>+murray : 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?
> 
>-JE : KSE should be able to run
>+julian : KSE should be able to run
> simple tests.
> 
>-DO : Is whatever you have
>+obrien : Is whatever you have
> committed by DP2 be the same as the release.
> 
>-JE : It will be a subset.
>+julian : It will be a subset.
> 
>-MS : What will the status be of
>+murray : What will the status be of
> KSE in userland for 5.0?
> 
>-JE : Can't answer that right
>+julian : 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.
> 
>-DO : Are we heading for a release?
>+obrien : Are we heading for a release?
> 
>-MS : yes.
>+murray : yes.
> 
>-DO : Then we have to stop having
>+obrien : Then we have to stop having
> major commits.
> 
>-MS : Yes, the discussion today is
>+murray : Yes, the discussion today is
> what are the major must have features.
> 
>-RW : We need to decide if there
>+rwatson : We need to decide if there
> are major upcoming problems and reduce risk on things like KSE.
> 
>-JE : That's why I want to get MS 3
>+julian : That's why I want to get murray 3
> in now.
> 
>-RW : Do you think that KSE related
>+rwatson : Do you think that KSE related
> changes from later milestones are going to be isolated to KSE or
> pervasive?
> 
>-JE : Hard to say. My guess is
>-that MS 4 stuff should be less pervasive.
>+julian : Hard to say. My guess is
>+that murray 4 stuff should be less pervasive.
> 
>-RW : What happens if KSE just
>+rwatson : What happens if KSE just
> doesn't work?
> 
>-JE : Well it does work, the
>+julian : 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.
> 
>-MD : KSEs only become fragile when
>+dillon : KSEs only become fragile when
> pthread uses them. That's the turning point.
> 
>-DO : I'd like the rules for the
>+obrien : I'd like the rules for the
> rest of the summer, I hope we'll talk about that.
> 
>-MS : Earlier is better.
>+murray : Earlier is better.
> 
>-JM : I think the cutoff point for
>-KSE might be MS 3.
>+mini : I think the cutoff point for
>+KSE might be murray 3.
> 
>-RW : It's the kind of thing where
>+rwatson : It's the kind of thing where
> if we need to back out we can.
> 
>-JE : If you're not going to run
>+julian : If you're not going to run
> KSEs then you're OK.
> 
>-RW : I think it's low risk. Let's
>+rwatson : I think it's low risk. Let's
> avoid the risk is the message.
> 
>-JE : The next DP2 (where we'd like
>-MS4).
>+julian : The next DP2 (where we'd like
>+murray4).
> 
>-AP : We really need KSE so all
>+alfred : 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.
> 
>-DO : We quickly need to figure out
>+obrien : We quickly need to figure out
> our policy on multiple archs.
> 
>-RW : I briefly want to respond to
>+rwatson : 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.
> 
>-JB : Realistically for the network
>+jhb : 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.
> 
>-RW : The GEOM stuff will be
>+rwatson : 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.
> 
>-JE : The kernel stuff is there but
>+julian : The kernel stuff is there but
> the user space is not. It can't become the default until everything
> is there.
> 
>-WL : What level of control are you
>+warner : What level of control are you
> going to exercise over the tree in the coming months?
> 
>-MS : You're going to see more
>+murray : You're going to see more
> level of control but we expect the requests to be reasonable. It's a
> very open process.
> 
>-JB : How are we going to address the 5/6 split?
>+jhb : How are we going to address the 5/6 split?
> 
>-MS : Carefully is all I can
>+murray : Carefully is all I can
> say.
> 
>-RW : For 5. 0 we need to have a
>+rwatson : 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.
> 
>-MS : Let's move it to more general
>+murray : Let's move it to more general
> discussion of DP2? Specific technologies.
> 
>-BM : Is there a strategy to lock
>+bmilekic : Is there a strategy to lock
> other protocols that are not locked down onw?
> 
>-DO : How much more do we need to
>+obrien : How much more do we need to
> do before 5.0?
> 
>-JB : Bug fixing is what we're doing.
>+jhb : Bug fixing is what we're doing.
> 
>-RW : The answer on the network
>+rwatson : The answer on the network
> stack. We need to choose a strategy on how to handle the other
> protocols.
> 
>-DO : The crux is that socket
>+obrien : The crux is that socket
> locking must be in 5.0.
> 
>-RW : There are 2 or 3 problems.
>+rwatson : There are 2 or 3 problems.
> Routing code is a problem. See earlier discussions.
> 
>-Doug : RCng is essentially done.
>+dfr : RCng is essentially done.
> What it needs is testers.
> 
>-AP : What about libh (I think libh
>+alfred : What about libh (I think libh
> is wrong but this is what I heard)?
> 
>-JB : It's very far along but not a
>+jhb : It's very far along but not a
> 5.0 thing.
> 
>-WL : Problems with interrupt
>-routing in ACPCI?
>+warner : Problems with interrupt
>+routing in alcPCI?
> 
>-Watanabe : Cannot handle PCI PCI
>+takawata : Cannot handle PCI PCI
> interrupt routing. Many 802.11x have this problem.
> 
>-JE : Is it a problem from Intel?
>+julian : Is it a problem from Intel?
> 
>-Watanabe : This is not an Intel
>+takawata : This is not an Intel
> problem but a problem on our side. PCI PCI routing code should be
> added. New code is necessary.
> 
>@@ -879,12 +887,12 @@ Whiteboard
> 
> UFS2		rcNG		KSE M3			CAM SMPng
> 
>-GEOM		TrustedBSD MAC	BusDMA			Newbus SMPng
>+GEOM		TrustedBSD Malc	BusDMA			Newbus SMPng
> 
> C++		Cardbus		libwhisk/sysinstall	KOBJ? (no!)
> 				sparc64
> 
>-Perl Removal	ACPI		Alpha SMP Stability	Pkgs for
>+Perl Removal	alcPI		Alpha SMP Stability	Pkgs for
> 							sparc64, IA64
> 
> devd		PCI intr route	document hints		release docs
>@@ -892,26 +900,26 @@ devd		PCI intr route	document hints		rel
> 							platform
> </pre>
> 
>-??? : Firewire?
>+unknown : Firewire?
> 
>-RW : What hardware shipping on
>+rwatson : What hardware shipping on
> IA64?
> 
>-DR : Intel stuff
>+dfr : Intel stuff
> 
>-RW : What about on Sparc64?
>+rwatson : What about on Sparc64?
> 
>-DO : Very limited (hme...)
>+obrien : Very limited (hme...)
> 
>-RW : KOBJ extensions discussed at
>+rwatson : KOBJ extensions discussed at
> BSDCon?
> 
>-WL : Not sure, probably not for
>+warner : Not sure, probably not for
> 5.0. Pervasive, so no.
> 
>-RW : How broken is C++?
>+rwatson : How broken is C++?
> 
>-DO : Only on sparc64. Don't
>+obrien : 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
>@@ -929,60 +937,60 @@ come release.
> 
> <div class="discussion">
> 
>-GT : Talking about rc.d stuff.
>+gordon : 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.
> 
>-RW : How in sync are the bits in
>+rwatson : How in sync are the bits in
> the new stuff with the old stuff.
> 
>-GT : Last patch is from June 3rd,
>+gordon : Last patch is from June 3rd,
> but it's tracking closely.
> 
>-RW : What is the schedule for
>+rwatson : What is the schedule for
> committing to the main tree.
> 
>-GT : We have large patches so
>+gordon : We have large patches so
> we're going to re-import from NetBSD.
> 
>-RW : How about you have it done by
>+rwatson : How about you have it done by
> July 1?
> 
>-GT : We could probably do that.
>+gordon : We could probably do that.
> Definitely want to be in DP2.
> 
>-GS : How long will we keep the old
>+gshapiro : How long will we keep the old
> stuff for?
> 
>-GT : We'll keep them both in for a
>+gordon : We'll keep them both in for a
> while. Not more than 1.5 months though.
> 
>-JE : Have you had a look at all at
>+julian : Have you had a look at all at
> the Mac OS/X startup code?
> 
>-GT : No.
>+gordon : No.
> 
>-JE : Do you deal with dependencies?
>+julian : Do you deal with dependencies?
> 
>-GT : There is meta data in each
>+gordon : There is meta data in each
> script that says what needs what. There is a program that orders
> everything correctly.
> 
>-??? : How does this effect the rc
>+unknown : How does this effect the rc
> script for ports install?
> 
>-GT : We could make this available
>+gordon : We could make this available
> to ports but won't on the first version.
> 
>-AP : Can I recommend that you
>+alfred : Can I recommend that you
> recommend this to ports?
> 
>-GT : Yes, the problem is that we
>+gordon : Yes, the problem is that we
> have so many ports.
> 
>-RW : The reason for this is for
>+rwatson : 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
>@@ -998,128 +1006,129 @@ system.
> 
> <div class="discussion">
> 
>-SL : I've been working on hardware
>+sam : 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.
> 
> <h3>Syscall vector change for 64bits</h3>
> 
> 
>-MD : Two ways to go. Need to
>+dillon : Two ways to go. Need to
> create a new syscall vector. The other is to do a 1 off replacement.
> Prefer the former.
> 
>-RW : Perhaps we need to create a
>+rwatson : Perhaps we need to create a
> FreeBSD 5 syscall vector. Could be a new ABI.
> 
>-JE : Aren't there enough other numbers?
>+julian : Aren't there enough other numbers?
> 
>-RW : That's one way to look at it
>+rwatson : That's one way to look at it
> and other platforms have done that? Is that too heavy weight?
> 
>-JE : It sounds that way to me.
>+julian : It sounds that way to me.
> You end up having to replicate the old ones into the new one.
> 
>-MD : The issue is about pollution.
>+dillon : The issue is about pollution.
> 
>-DR : Seems like too much work for 5.x
>+dfr : Seems like too much work for 5.x
> 
>-JE : It's more work. There are
>+julian : It's more work. There are
> now two places. Why not talk to OpenBSD?
> 
>-RW : Should there be a BSD API?
>+rwatson : Should there be a BSD alfredI?
> Tough to do across projects.
> 
>-DO : Who here is going to see that
>+obrien : Who here is going to see that
> through? We have not talked to NetBSD about even SMP.
> 
>-AP : Does changing the syscall
>+alfred : Does changing the syscall
> table allow us to do clean up?
> 
>-RW : We could do that without
>+rwatson : We could do that without
> doing 64bit syscall table.
> 
> <h3>5.x ABI stability</h3>
> 
> 
>-RW : There are new functions in
>+rwatson : There are new functions in
> 5.x. At what point do we stop changing?
> 
>-DR : When people start really using it.
>+dfr : When people start really using it.
> 
>-RW : How do we tell? How did Solaris do it?
>+rwatson : How do we tell? How did Solaris do it?
> 
>-Everyone : Know one knows.
>+Everyone : No one knows.
> 
>-DR : It's too hard to add a
>+dfr : It's too hard to add a
> syscall vector. Library issues are a problem.
> 
>-DO : We can use ELF to handle that.
>+obrien : We can use ELF to handle that.
> 
>-DR : Let's just add 20 new
>+dfr : Let's just add 20 new
> syscalls instead of adding new work that we don't really really need.
> 
>-RW : Punt on lack of time to do
>+rwatson : Punt on lack of time to do
> this.
> 
>-MD : I see DO's point with the
>+dillon : I see obrien's point with the
> libraries but I have done this with time_t at 64 bits.
> 
> <h3>devd</h3>
> 
> 
>-RW : The devd stuff was to
>+rwatson : The devd stuff was to
> integrate cardbus, newbus, etc.
> 
>-JE : To monitor requests to mount
>+julian : To monitor requests to mount
> or create new devices.
> 
>-RW : Is this a 5.0 requirement?
>+rwatson : Is this a 5.0 requirement?
> Is there anyone to do this?
> 
>-GT (from IRC) : PHK has patches
>+
>+gordon (from IRC) : PHK has patches
> that make having devd unnecessary.
> 
>-BD : Need something that does what
>+brooks : Need something that does what
> pccardd did. 
> 
>-JE : Need to be able to do this
>+julian : Need to be able to do this
> through a file. 
> 
>-WL : (from IRC): That's a 6.0
>+warner : (from IRC): That's a 6.0
> feature.
> 
>-JE : It would not be a large step
>+julian : It would not be a large step
> to put something in the middle to handle this.
> 
>-JE : Sometime in the 5 lifetime we
>+julian : Sometime in the 5 lifetime we
> need this.
> 
>-WL : There is no way to monitor
>+warner : There is no way to monitor
> events in newbus but it would be easy to add.
> 
>-JE : I'm not sure I understood you
>+julian : I'm not sure I understood you
> correctly.
> 
>-WL : What happens now in a PCI is
>+warner : 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.
> 
>-JB : Mike Smith gave us an
>+jhb : Mike Smith gave us an
> informal tour of OS/X. OS/X uses XML to do this. They have the DEVID
> in XML.
> 
>-BD : I looked at some PCI drivers
>+brooks : I looked at some PCI drivers
> and some work that way but some don't.
> 
>-JE : It seems to me we need to not
>+julian : 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.
> 
>-RW : Time up, time to wrap up.
>+rwatson : Time up, time to wrap up.
> </div>
> 
> &footer;

Actions: View | Diff

Attachments on bug 42512: 24921