On 08/10/17 07:50, Spencer E Olson wrote:
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@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.
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?
Python is used for building documentation and for various analysis
tools, but is not currently a prerequisite for a "normal" kernel build.
Perl has always been a prerequisite, but I don't know which optional
Perl modules (from CPAN) are required.
--
-=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@xxxxxxxxx> )=-
-=( Web: http://www.mev.co.uk/ )=-
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
