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

[Ian Abbott]

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 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?

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 at mev.co.uk> )=-
-=(                          Web: http://www.mev.co.uk/  )=-