[staging] High level Comedi feedback

[Shawn Bohrer <shawn.bohrer@ni.com>]

Hey All,

After reviewing the design of COMEDI there are a few concerns we've
found that could inhibit COMEDI as a general data acquisition framework.
I can elaborate on any of these concerns if needed, and I'd appreciate
any feedback from those who are more familiar with the COMEDI drivers.

1. COMEDI lacks a state model (configure, reserve, commit, start, stop)
that allows for speedy programming, reserving, and starting and stopping
when multiple clients are vying for usage of the shared hardware and
setup/tear-down costs have to be minimized.  The comedi_cmd interface
forces the setup costs to be incurred for every acquisition this is a
performance liability.  The other downside of this interface is that it
does not allow for on-the-fly settings changes such as changing an
acquisition rate or ranges of a channel within a running
acquisition/generation.

2. In general I'm concerned that the comedi_cmd_struct can't be expanded
to support all of the possible timing configurations of existing
hardware.

3. COMEDI expresses timing in terms of nano-seconds, limiting the scan
rate to 1GHz, scopes can go higher than this. The ~4,200V and 4.2A
limits brought by the range scaling coefficients are often suitable, but
could be a problem later with signal conditioned boards. Would value +
unit or value + multiplier be better?

4. COMEDI lacks the fine grained resource reservation (digital lines,
specific routes).

5. COMEDI does not yet support memory mapped digital lines or memory
mapped single point reads/writes directly with the hardware.

6. COMEDI doesn't yet support configuring hardware buffer sizes for deep
on-board FIFOs.

7. The comedi_bond.c driver doesn't attempt any synchronization and
doesn't support buffered operations. These features could be added, in
the kernel, but wouldn't this be better done in user-mode?

--
Shawn