Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

===================================================================
RCS file: /ftp/cvs/cvsroot/src/doc/BRANCHES,v
rcsdiff: /ftp/cvs/cvsroot/src/doc/BRANCHES,v: warning: Unknown phrases like `commitid ...;' are present.
retrieving revision 1.214
retrieving revision 1.215
diff -u -p -r1.214 -r1.215
--- src/doc/BRANCHES	2007/10/18 15:31:17	1.214
+++ src/doc/BRANCHES	2007/10/18 23:50:10	1.215
@@ -1,4 +1,4 @@
-#	$NetBSD: BRANCHES,v 1.214 2007/10/18 15:31:17 yamt Exp $
+#	$NetBSD: BRANCHES,v 1.215 2007/10/18 23:50:10 ad Exp $
 #
 # This file contains a list of branches that exist in the NetBSD CVS
 # tree and their current state.
@@ -521,53 +521,86 @@ Notes:		This branch is based off of the 
 		able to pthread_kill() running threads.
 
 Branch:		vmlocking
-Description:	Make memory allocators and trap handling MP safe
+Description:	Make VM and file system framework MP safe
 Status:		Active
 Start Date:	13 March 2007
 End Date:
 Base Tag:	vmlocking-base
 Maintainer:	Andrew Doran <ad@NetBSD.org>
 Scope:		kernel
-Notes:
-		- Replace all simplelocks with mutexes
-		- Remove spinlockmgr
-		- Make memory allocators MP safe
-		- Make trap handling MP safe: push kernel lock acquire
-		  back into pager ops.
-
-		Only i386 is currently update.  Most per architecture
-		changes need to be made in the pmap module.  LFS is not
-		currently stable due interaction between the pagedaemon (?)
-		and the HOLDRELE() in lfs_segment.c.  It may trash your
-		filesystem..
-
-		Most of the locks replaced are now sleep/adaptive locks or
-		spin locks at IPL_VM.  Assuming audio interrupt handlers
-		are made MP safe there are far fewer potential deadlocks
-		against the kernel lock.
-
-		v_interlock becomes an adaptive mutex so now acquring
-		it can potentially block, similarly for other locks
-		that were before simplelocks.  This needs to be audited
-		carefully.
-
-		Use vnodes in general needs to be audited, as vnodes can
-		now be inspected without the kernel lock held.
-
-		Acquiring locks in the pmap module can now block, meaning
-		that the current pmap, cpu or lazy pmap status can change
-		out from underneath the requestor.  This also needs to be
-		audited.
-
-		Currently, i386 has the necessary modifications, and has
-		trap handling and a few calls to allocators out from under
-		the kernel lock.  There are still problems that need to be
-		debugged.
+Notes:		Goals:
+
+		- Make VM system / trap handling MP safe.
+		- Replace simplelocks with mutexes.
+		- Make file system framework MP safe.
+
+		Status by architecture:
+
+		  alpha			partial: pmap.c/trap.c need work
+		  i386			done
+		  amd64			done
+		  mips			partial: !pmax needs work
+		  sparc			
+		  sparc64		
+		  arm			
+		  macppc/powerpc	
+		  hppa			
+		  sh3			
+		  vax			
+		  m68k			
+
+		Remaining MI work to do:
+
+		- subr_pool/pagedaemon needs to use crosscalls to invalidate
+		  per-cpu pool_cache elements.
+
+		- Clean up vfs_busy/vfs_unbusy and mount/dounmount semantics
+		  so that lockmgr is not being used any more. Reference
+		  counting on struct mount is probably the best solution.
+
+		- Check locking around fields in struct mount.
+
+		- Check file systems that traverse mounpoint vnode lists.
+		  They need to use marker vnodes.
+
+		- Double check that revoke / forced unmount is still safe
+		  (it might never have been!).
+
+		- Re-write the itimer code to be MP safe and work in the
+		  presence of threaded soft interrupts.
+
+		- Defer x86 npxsave interrupts to an process context (do
+		  aston() and handle from trap.c).
+
+		- Check aliased vnode handling. There may be problems.
+
+		Remaining problems:
+
+		- tmpfs_rmdir occasionally leaks tmpfs_nodes. This could be
+		  an old problem but either way it needs to be fixed.
+
+		- UVM_FLAG_TRYLOCK is not sufficient in uvm_km.c because
+		  allocations will fail too often. It's needed for !kmem_map
+		  because sometimes allocations are made by threads that
+		  hold the map locked, which could cause other threads to
+		  wait long term even if they are trying to make a NOWAIT
+		  allocation.
+
+		- softdep: "unmount pending error". It looks like free
+		  bitmaps are not being updated in some cases. Does not
+		  pose a corruption risk but needs to be fixed.
+
+		- softdep: allocation failure on a full file system
+		  will deadlock the system because we try to flush
+		  out free pages in order to resolve dependencies.
+		  On head, it panics the system: just comment out the
+		  fix for now.
+
+		- ffs+snapshots needs testing.
 
-		Need to check that whenever a lock is initialized, it is
-		also destroyed.
+		- LFS port has been fudged and it's probably borked.
 
-		Lots of testing required.
+		- Report of ext2fs panic on unmount.
 
 Branch:		yamt-lazymbuf
 Description:	implement and evaluate lazy mapping of mbuf external data pages