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@xxxxxxxxx> > >>> > >>> *** 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 devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
