[PATCH 00/15] device-global identifiers and routes introduced

[Greg Kroah-Hartman]

On Wed, Oct 12, 2016 at 05:05:07AM -0600, Spencer E. Olson wrote:
> This patchset introduces a new framework for providing and maintaining a
> consistent namespace to define terminal/signal names for a set of comedi
> devices.  This effort was primarily focused on supporting NI hardware, but the
> interfaces introduced here can be implemented by all other hardware drivers, if
> desired.  Otherwise, these new interfaces do not effect any interfaces
> previously defined or prior use cases (i.e. backwards compatibility).
> 
> Some background:
>   There have been significant confusions over the past many years for users
>   when trying to understand how to connect to/from signals and terminals on
>   NI hardware using comedi.  The major reason for this is that the actual
>   register values were exposed and required to be used by end users.  Several
>   major reasons exist why this caused major confusion for users:
> 
>   1) The register values are _NOT_ in user documentation, but rather in
>     arcane locations, such as a few register programming manuals that are
>     increasingly hard to find.  Some information is found in the register level
>     programming libraries provided by National Instruments (NI-MHDDK), but
>     many items are only vaguely found/mentioned in the comments of the NI-MHDDK
>     example code.  There is no one place to find the various valid values of the
>     registers.
> 
>   2) The register values are _NOT_ completely consistent.  There is no way to
>     gain any sense of intuition of which values, or even enums one should use
>     for various registers.  There was some attempt in prior use of comedi to
>     name enums such that a user might know which enums should be used for
>     varying purposes, but the end-user had to gain a knowledge of register
>     values to correctly wield this approach.
> 
>   3) The names for signals and registers found in the various register level
>     programming manuals and vendor-provided documentation are _not_ even
>     close to the same names that are in the end-user documentation.
> 
>   4) The sets of routes that are valid are not consistent from device to device.
>     One additional major challenge is that this information is not documented
>     and does not seem to be obtainable in any programmatic fashion, neither
>     through the proprietary NIDAQmx(-base) c-libraries, nor with register level
>     programming.  In fact, the only consistent source of this information is
>     through the proprietary NI-MAX software, which currently only runs on
>     Windows platforms.  A further challenge is that this information cannot be
>     exported from NI-MAX, except by screenshot.
> 
> Similar confusion, albeit less, plagued NI's previous version of their own
> proprietary drivers.  Earlier than 2003, NI greatly simplified the situation for
> users by releasing a new API that abstracted the names of signals/terminals to a
> common and intuitive set of names.  In addition, this new API provided a much
> more common interface to use for most of NI hardware.
> 
> Comedi already provides such a common interface for data-acquisition and control
> hardware.  This effort complements comedi's abstraction layers by further
> abstracting much more of the use cases for NI hardware, but allowing users _and_
> developers to directly refer to NI documentation (user-level, register-level,
> and the register-level examples of the NI-MHDDK).
> 
> The goal of these patches are:
>   0) Allow current code to function as is, providing backwards compatibility to
>     the current interface, following a suggestion by Eric Piel.
>   1) Provide an interface to connect routes or identify signal sources and
>     destinations using a consistent naming scheme, global to a driver family.
>   2) For NI devices, use terminal/signal naming that is consistent with (a) the
>     NI's user level documentation, (b) NI's user-level code, (c) the information
>     as provided by the proprietary NI-MAX software, and (d) the user interface
>     code provided by the user-land comedilib library.
>   3) Make for easy maintenance of register level values that are to be used for
>     any particular NI device of any particular NI device family.
>   4) Provide a means whereby the user can query the set of signal routes that is
>     valid for a particular device.
>   5) Provide an interface whereby the user can query the status and capability
>     of any signal route.  The driver can provide information on whether the
>     route is valid for the device and whether the route is already connected.
> 
> This patch set implements various changes that keep the goals set forth here.
> This patch set is in nowise complete with respect to the various NI hardware
> options supported by comedi, though a large selection should be supported--all
> e/m-series (ni_mio_common.c hardware) boards and 660x boards are the target of
> this patch set, including the tio devices (counter/timers) used by these boards.
> 
> A copy of these patches can be found at:
> http://www.umich.edu/~olsonse/patches/comedi-devglobal-v1/
> 
> Cc: Eric Piel <piel at delmic.com>

No comment on these patches?  At first glance, they look like a good
idea to me, but I really don't know the comedi subsystem very well...

Ian?

thanks,

greg k-h