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*