[PATCH 04/15] staging: comedi: ni_routing: add ni routing tables

Spencer E Olson olsonse at umich.edu
Sun Oct 8 06:50:17 UTC 2017


On Thu, 2016-11-10 at 11:27 -0700, Spencer E Olson wrote:
> On Thu, 2016-11-10 at 18:18 +0000, Ian Abbott wrote:
> > On 10/11/16 17:54, Greg Kroah-Hartman wrote:
> > > On Thu, Nov 10, 2016 at 05:17:22PM +0000, Ian Abbott wrote:
> > >> On 12/10/16 12:05, Spencer E. Olson wrote:
> > >>> Adds tables of all register values for routing various signals to various
> > >>> terminals on National Instruments hardware.  This information is directly
> > >>> compared to and taken from register-level programming documentation and/or
> > >>> register-level programming examples as provided by National Instruments.
> > >>>
> > >>> Furthermore, this information was mostly compared (favorably) to the
> > >>> register values already used in the comedi drivers for NI hardware.
> > >>>
> > >>> Adds tables of valid routes for many devices.  This information is not
> > >>> consistent from device to device, nor entirely consistent within device
> > >>> families.  One additional major challenge is that this information does not
> > >>> seem to be obtainable in any programmatic fashion, neither through the
> > >>> proprietary NIDAQmx(-base) c-libraries, nor with register level
> > >>> programming, _nor_ through any documentation.  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.
> > >>>
> > >>> As described in ni_routing/README and as provided by this commit, the
> > >>> device route information is primarily stored in a spreadsheet so-as to
> > >>> enhance the ability to compare to screenshots obtained of NI-MAX.  This
> > >>> commit provides the ability to parse the spreadsheets and generate
> > >>> code following kernel conventions.
> > >>>
> > >>> Signed-off-by: Spencer E. Olson <olsonse at umich.edu>
> > >>>
> > >>> *** PLEASE FIND ACTUAL PATCH AT:
> > >>> http://www.umich.edu/~olsonse/patches/comedi-devglobal-v1/0004-staging-comedi-ni_routing-add-ni-routing-tables.patch
> > >>>
> > >>> (This patch was over 500kB in size, too large for inline patch submission)
> > >>> ---
> > >>>  .../staging/comedi/drivers/ni_routing/.gitignore   |     3 +
> > >>>  drivers/staging/comedi/drivers/ni_routing/Makefile |    40 +
> > >>>  .../comedi/drivers/ni_routing/extract_tables.py    |   259 +
> > >>>  .../comedi/drivers/ni_routing/ni_device_routes.c   | 20251 +++++++++++++++++++
> > >>>  .../comedi/drivers/ni_routing/ni_route_values.c    |  2724 +++
> > >>>  5 files changed, 23277 insertions(+)
> > >>>  create mode 100644 drivers/staging/comedi/drivers/ni_routing/.gitignore
> > >>>  create mode 100644 drivers/staging/comedi/drivers/ni_routing/Makefile
> > >>>  create mode 100755 drivers/staging/comedi/drivers/ni_routing/extract_tables.py
> > >>>  create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_device_routes.c
> > >>>  create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_route_values.c
> > >>>
> > >>> <... SNIP ...>
> > >>>
> > >>
> > >> The file heading comments in ni_device_routes.c and ni_route_values.c have
> > >> completely blank lines that need filling in.
> > >>
> > >> I'm not sure if the fact that this patch cannot be emailed is a problem for
> > >> it to be accepted.  Since the problem is the number of lines, perhaps it can
> > >> be split?
> > >
> > > Why not auto-generate the .c files from the csv files as part of the
> > > kernel build process?  We do that today for other auto-generated files.
> > 
> > At the moment, the C files are generated by a Python script.  Is that 
> > acceptable for a "normal" kernel build?
> > 
> 
> I'm not against just auto-generating the .c files.  I couldn't actually
> identify something similar in the kernel, but if that already occurs...
> 
> I do think that keeping the .csv files is critical, since they will
> facilitate maintenance and also addition of new hardware support the
> easiest.  
> 
> I'd rather not re-implement the script, but I supposed that is not out
> of the question.  I was trying to capitalize on standard packages (only)
> from python that let me implement the script is some succinct(ish)
> fashion.
> 

As I am going through to get this patchset ready for resubmission after
a long hiatus, I think I was expecting at least some type of response on
my last email above.  The issues are pertaining to generating .c files
perhaps as late as at compile time and also the means of this .c-file
generation.  I used Python for the reasons described above.  Is it
critical that these conversion scripts be re-implemented in Perl?



More information about the devel mailing list