todo.md

 ## Things to fix and add in ZIO
 
-### Fixes and audit For the next "release", which will be beta3, submittable to the kernel
+Even if beta 3 has been tagged in the repository and the patch has been
+sent out, the design phase is not finalized, and some things are still
+pending.
 
-  - Support for writing the control block even for input channels
+### Code Changes
+
+  - Implement the bus abstraction, to split drivers and devices
 
 <!-- end list -->
 
-  - Evaluate a DECLARE\_ZIO\_NAME() so you can name your structures
+  - Make a single zio-core.ko module that includes default trigger and
+    buffer
 
 <!-- end list -->
 
-  - Make a serious study of all race conditions, especially the problem
-    of output configs where the trigger has not yet fired
+  - Use cdev permissions so input is RO and output is WO
 
 <!-- end list -->
 
-  - Check all allocations and deallocations
+  - Add a binary control block in /sys to reflect current status and set
+    config
 
 <!-- end list -->
 
-  - Make a single zio-core.ko module that includes defualt trigger and
-    buffer
+  - Use owned kmem\_cache structures for control blocks and other
+    fixed-size structures
 
 <!-- end list -->
 
-  - Add more working examples, also for real harware
+  - Add code to change a trigger and a buffer at run time
 
-#### New features
+<!-- end list -->
 
-  - Implement the bus abstraction, to split drivers and devices
+  - Support DMA to user space
+
+### New Features
+
+A discussion of our suggestion for these is on the mailing list archive:
+http://lists.ohwr.org/sympa/arc/zio/2011-11/msg00026.html
+
+  - Interleaved channels
+
+<!-- end list -->
+
+  - Double buffering
+
+<!-- end list -->
+
+  - Multi-threaded access
+
+<!-- end list -->
+
+  - fasync support
+
+<!-- end list -->
+
+  - Complex data structures
+
+<!-- end list -->
+
+  - Channel flags and alarms
+
+### New Drivers
+
+  - Cleanup and publish the AD7888 driver we are using internally
+
+<!-- end list -->
+
+  - Complete and publish the line discipline for uart-driven input and
+    output
+
+<!-- end list -->
+
+  - Add a cset to zio-zero with internal timing for samples
+
+<!-- end list -->
+
+  - Write drivers/zio-gpio.c for input and output with cset-level rate
+    selection
+
+<!-- end list -->
+
+  - Write triggers/zio-trig-app-request (transparent trigger for
+    streaming); this will be the default trigger
+
+<!-- end list -->
+
+  - Write an example buffer using special (non-kmalloc) memory
+
+<!-- end list -->
+
+  - Write a buffers/zio-buf-circ, a buffer that discards control
+    structures and regenerates them as needed, to reduce overhead when
+    little blocks are used.
+
+<!-- end list -->
+
+  - Write a trigger based on high-resolution timers
+
+<!-- end list -->
+
+  - Write more drivers for real hardware (accelerometers, DACs and so
+    on)
+
+### Audit, Consistency, Documentation
+
+  - Update documentation to really reflect code status
+
+<!-- end list -->
+
+  - Make zio-core include 
 
 <!-- end list -->
 
-  - Implement an enable/disable policy, so enabling channels may disable
-    competing channels in another cset
+  - Audit all spinlocks and related stuff, writing a policy for drivers
+    triggers and buffer
 
 <!-- end list -->
 
-  - Write a kmem\_cache for the control structures
+  - Audit all allocations, again writing a policy document
 
 <!-- end list -->
 
-  - Write the app-request trigger, that should be the default one
+  - Offer defaults in zio-core wherever possible, likes push\_block
 
 <!-- end list -->
 
-  - Write a circular buffer, that frees control structures and recreates
-    them as needed
+  - Remove file operations from triggers, offer zio\_generic\_fops and
+    write a policy document
 
 <!-- end list -->
 
-  - Think about the details of mmap support and DMA to user space
+  - Define an enable/disable policy for channel and csets; use and
+    document it.