From: sjg
Date: Fri, 22 Feb 2013 08:36:27 +0000 (-0800)
Subject: (no commit message)
X-Git-Url: http://gitweb.dragonflybsd.org/ikiwiki.git/commitdiff_plain/c52e2798c6a73ea60c08a6f61d14a07ac348e3a5
---
diff --git a/docs/developer/ProjectsPage.mdwn b/docs/developer/ProjectsPage.mdwn
index b38b811..ca43479 100644
--- a/docs/developer/ProjectsPage.mdwn
+++ b/docs/developer/ProjectsPage.mdwn
@@ -212,10 +212,6 @@ Projects that can be clearly used for Google Code-In are marked with their categ
* A device that uses physical memory as swap space, but compresses it.
* Do we support stacking of swap space? For example, one would have this compressed in-memory swap device with highest priority. Replaced objects will be put into the next priority swap device (e.g. a SSD), and so on.
-### tmpfs allocations from swap
-* Currently, tmpfs nodes and stuff are allocated from KVA are the size limiter for a tmpfs filesystem
-* Instead allocate them from swappable memory; this will allow larger tmpfses up to swap limits
-
### mmap MAP_ALIGN
* Solaris's mmap support a flag, MAP_ALIGN, where the address to mmap acts as an alignment hint
* Our backing VM calls support an alignment parameter, but our public mmap does not
@@ -237,7 +233,7 @@ Projects that can be clearly used for Google Code-In are marked with their categ
### Tear out condvars
* Conditional vars -- condvar(9), could be replaced with other locking primitives and our tsleep/wakeup interlock.
-### Make karc4random in libkern per-cpu
+### Make karc4random in libkern per-cpu (or at least wrap its own token around it)
* Verify that it is possible and safe to do this, what care would need to be taken, especially with respect to the random seeding?
* Pull out locks around calls to karc4rand*