[PATCH 04/15] staging: comedi: ni_routing: add ni routing tables
Spencer E Olson
olsonse at umich.edu
Thu Nov 10 18:27:24 UTC 2016
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.
More information about the devel
mailing list