[staging] High level Comedi feedback

[staging] High level Comedi feedback

[Shawn Bohrer]

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

Re: [staging] High level Comedi feedback

[Frank Mori Hess]

[-- Attachment #1: Type: text/plain, Size: 435 bytes --]

On Monday 09 February 2009 13:01, Shawn Bohrer wrote:
> 6. COMEDI doesn't yet support configuring hardware buffer sizes for deep
> on-board FIFOs.

There is INSN_CONFIG_BLOCK_SIZE, which a couple drivers use to configure 
their hardware fifo size.

By the way, I'm not subscribed to linux-kernel.  Comedi does have its own 
mailing list, maybe this kind of discussion would be easier on a more 
specific, lower traffic list?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [staging] High level Comedi feedback

[Shawn Bohrer]

Hey Frank,

On Mon, Feb 09, 2009 at 10:38:44PM -0500, Frank Mori Hess wrote:
> On Monday 09 February 2009 13:01, Shawn Bohrer wrote:
> > 6. COMEDI doesn't yet support configuring hardware buffer sizes for deep
> > on-board FIFOs.
>
> There is INSN_CONFIG_BLOCK_SIZE, which a couple drivers use to configure
> their hardware fifo size.

Thanks I'll take a close look at this.

> By the way, I'm not subscribed to linux-kernel.  Comedi does have its own
> mailing list, maybe this kind of discussion would be easier on a more
> specific, lower traffic list?

Since Comedi is working its way into the kernel I'd like to get a
little broader exposure on some of the things that we'd like to see
improved before any interfaces get set in stone.  I think it could be
beneficial to cc the Comedi list, but it looks like that list only
accepts emails from subscribers.

--
Shawn

Re: [staging] High level Comedi feedback

[Greg KH]

On Wed, Feb 11, 2009 at 05:17:28PM -0600, Shawn Bohrer wrote:
> Hey Frank,
> 
> On Mon, Feb 09, 2009 at 10:38:44PM -0500, Frank Mori Hess wrote:
> > On Monday 09 February 2009 13:01, Shawn Bohrer wrote:
> > > 6. COMEDI doesn't yet support configuring hardware buffer sizes for deep
> > > on-board FIFOs.
> >
> > There is INSN_CONFIG_BLOCK_SIZE, which a couple drivers use to configure
> > their hardware fifo size.
> 
> Thanks I'll take a close look at this.
> 
> > By the way, I'm not subscribed to linux-kernel.  Comedi does have its own
> > mailing list, maybe this kind of discussion would be easier on a more
> > specific, lower traffic list?
> 
> Since Comedi is working its way into the kernel I'd like to get a
> little broader exposure on some of the things that we'd like to see
> improved before any interfaces get set in stone.  I think it could be
> beneficial to cc the Comedi list, but it looks like that list only
> accepts emails from subscribers.

The Comedi interface is not set in stone at all yet.  I've just
integrated the core, and am still adding the remaining drivers
(hopefully get to the rest of them tomorrow).  Then we can start
cleaning up the interfaces between the core and drivers, and review the
external interface as well, to see if it is lacking in any way, or not
working properly for any specific users (like yourself.)

Sound good?

thanks,

greg k-h