linux-kernel - [staging] High level Comedi feedback

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090209180144.GD18058@bohrers.amer.corp.natinst.com>
Date:	Mon, 9 Feb 2009 12:01:44 -0600
From:	Shawn Bohrer <shawn.bohrer@...com>
To:	linux-kernel@...r.kernel.org
Cc:	gregkh@...e.de, abbotti@....co.uk, fmhess@...rs.sourceforge.net,
	ds@...leef.org
Subject: [staging] High level Comedi feedback

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/