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 <olso...@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.

_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Reply via email to