update codegen-fu
authorsjg <sjg@web>
Thu, 2 Sep 2010 00:10:30 +0000 (17:10 -0700)
committerCharlie <root@leaf.dragonflybsd.org>
Thu, 2 Sep 2010 00:10:30 +0000 (17:10 -0700)
docs/developer/researchprojectspage/index.mdwn

index db01aa6..8402acd 100644 (file)
@@ -12,15 +12,19 @@ Please feel free to add projects to this page, or annotate existing project idea
 * Well defined kernel build mechanisms for code generation
 * This will require discussion
 
-### On-disk / Over-the-wire structure codegen
+### On-disk / Over-the-wire structure codegen + CAPS
 * Somewhat analogous to google protocol buffers / etc.
-* Take a normalized definition of data, metadata, an operation and generate a structure, serialization routines and accessor routines for it/them
+* Take a normalized definition of data, metadata or an operation and generate a structure, serialization routines and accessor routines for it/them
 * Must be able to generate structs binary compatible with existing on-disk formats (including warts)
 * Should magically create formats that are 32/64bit agnostic OR fixup serializers/unserializers
 * Accessor routines and thread safety? Do we make you hang these objects somewhere that you store your synchronization objects or allow you to include them?
-* Versioning?
+* Optional versioning?
 * Potential uses: ... HAMMER, UFS, HAMMER mirror streams, message passing, ...
-* QUESTIONS: Would people actually use them?
+* CAPS (DragonFly's message passing system, which exists but is not functional at the time of this writing) has an over-the-wire format with serialization/deserialization. This codegeneration serialization solution should be amenable to the purposes of CAPS or whatever future message passing infrastructure might be implemented in DragonFly.
+* CAPS References: [1](http://www.shiningsilence.com/dbsdlog/2003/11/25/139.html#more-139
+) [2](http://www.shiningsilence.com/dbsdlog/2004/03/07/293.html#more-293
+) [3](http://www.shiningsilence.com/dbsdlog/2004/04/24/365.html#more-365
+)
 
 ### Asynchronous system call framework
 * Probably best implemented as a message passing interface to kernel pass messages in, threads pick them up and execute, return through kevent notifications