[PATCH 03/15] staging: comedi: ni_routing: Add NI signal routing info
Spencer E Olson
olsonse at umich.edu
Thu Oct 12 05:09:32 UTC 2017
On Mon, 2017-10-09 at 12:01 -0600, Spencer E Olson wrote:
> On Mon, 2017-10-09 at 10:56 +0100, Ian Abbott wrote:
> > On 08/10/17 07:44, Spencer E Olson wrote:
> > > On Thu, 2016-11-10 at 18:16 +0000, Ian Abbott wrote:
> > >> On 10/11/16 17:54, Greg Kroah-Hartman wrote:
> > >>> On Thu, Nov 10, 2016 at 05:08:36PM +0000, Ian Abbott wrote:
> > >>>> On 12/10/16 12:05, Spencer E. Olson wrote:
> > >>>>> See README for a thorough discussion of this content.
> > >>>>>
> > >>>>> Adds two different collections of CSV files that:
> > >>>>> 1) summarize the various register values for creating routes
> > >>>>> for a particular family of NI hardware devices;
> > >>>>> 2) summarize all possible (direct) routes that a particular device can
> > >>>>> make--in this case, one file per device (this data is currently only
> > >>>>> known to be found by examining a screenshot of the "Available Routes"
> > >>>>> tab of NI MAX control panel, which is only found on Windows
> > >>>>> installations of the NI driver).
> > >>>>>
> > >>>>> The collection and maintenance of this information is somewhat tedious and
> > >>>>> requires frequent re-examination and comparison of NI-MAX and/or the NI-MHDDK
> > >>>>> documentation (register programming information) and NI-MHDDK examples.
> > >>>>> These CSV files are constructed so-as to allow near direct comparison
> > >>>>> to NI-MAX and NI-MHDDK. As such, these serve to ease the task of
> > >>>>> maintaining this knowledge and more quickly enables addition of new NI
> > >>>>> devices.
> > >>>>>
> > >>>>> Signed-off-by: Spencer E. Olson <olsonse at umich.edu>
> > >>>>>
> > >>>>> *** PLEASE FIND ACTUAL PATCH AT:
> > >>>>> http://www.umich.edu/~olsonse/patches/comedi-devglobal-v1/0003-staging-comedi-ni_routing-Add-NI-signal-routing-info.patch
> > >>>>>
> > >>>>> (This patch included some lines that were too long for email)
> > >>>>> ---
> > >>>>> drivers/staging/comedi/drivers/ni_routing/README | 110 +++++++++++++++++++++
> > >>>>> .../ni_routing/ni_device_routes/PCI-6070E.csv | 40 ++++++++
> > >>>>> .../ni_routing/ni_device_routes/PCI-6220.csv | 46 +++++++++
> > >>>>> .../ni_routing/ni_device_routes/PCI-6221.csv | 50 ++++++++++
> > >>>>> .../ni_routing/ni_device_routes/PCI-6251.csv | 51 ++++++++++
> > >>>>> .../ni_routing/ni_device_routes/PCI-6254.csv | 47 +++++++++
> > >>>>> .../ni_routing/ni_device_routes/PCI-6259.csv | 51 ++++++++++
> > >>>>> .../ni_routing/ni_device_routes/PCI-6534.csv | 29 ++++++
> > >>>>> .../ni_routing/ni_device_routes/PCI-6602.csv | 78 +++++++++++++++
> > >>>>> .../ni_routing/ni_device_routes/PCI-6713.csv | 32 ++++++
> > >>>>> .../ni_routing/ni_device_routes/PCI-6723.csv | 32 ++++++
> > >>>>> .../ni_routing/ni_device_routes/PCI-6733.csv | 34 +++++++
> > >>>>> .../ni_routing/ni_device_routes/PXI-6030E.csv | 39 ++++++++
> > >>>>> .../ni_routing/ni_device_routes/PXI-6224.csv | 46 +++++++++
> > >>>>> .../ni_routing/ni_device_routes/PXI-6225.csv | 49 +++++++++
> > >>>>> .../ni_routing/ni_device_routes/PXI-6251.csv | 50 ++++++++++
> > >>>>> .../ni_routing/ni_device_routes/PXI-6733.csv | 35 +++++++
> > >>>>> .../ni_routing/ni_device_routes/PXIe-6251.csv | 52 ++++++++++
> > >>>>> .../drivers/ni_routing/ni_route_values/ni_660x.csv | 100 +++++++++++++++++++
> > >>>>> .../ni_routing/ni_route_values/ni_eseries.csv | 78 +++++++++++++++
> > >>>>> .../ni_routing/ni_route_values/ni_mseries.csv | 90 +++++++++++++++++
> > >>>>> 21 files changed, 1139 insertions(+)
> > >>>>> create mode 100644 drivers/staging/comedi/drivers/ni_routing/README
> > >>>>> create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PCI-6070E.csv
> > >>>>> create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PCI-6220.csv
> > >>>>> create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PCI-6221.csv
> > >>>>> create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PCI-6251.csv
> > >>>>> create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PCI-6254.csv
> > >>>>> create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PCI-6259.csv
> > >>>>> create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PCI-6534.csv
> > >>>>> create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PCI-6602.csv
> > >>>>> create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PCI-6713.csv
> > >>>>> create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PCI-6723.csv
> > >>>>> create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PCI-6733.csv
> > >>>>> create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PXI-6030E.csv
> > >>>>> create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PXI-6224.csv
> > >>>>> create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PXI-6225.csv
> > >>>>> create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PXI-6251.csv
> > >>>>> create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PXI-6733.csv
> > >>>>> create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PXIe-6251.csv
> > >>>>> create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_route_values/ni_660x.csv
> > >>>>> create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_route_values/ni_eseries.csv
> > >>>>> create mode 100644 drivers/staging/comedi/drivers/ni_routing/ni_route_values/ni_mseries.csv
> > >>>>>
> > >>>>> <... SNIP ...>
> > >>>>>
> > >>>>
> > >>>> While it's nice to have the source data for the generated C files, I'm a bit
> > >>>> worried that any future patches to these .csv files will also be
> > >>>> incompatible with sending by email. I'm not sure of the best way to deal
> > >>>> with this.
> > >>>
> > >>> They should work in email, it's just a text file and patch handles that
> > >>> fine.
> > >>>
> > >>
> > >> Its the line lengths I'm worried about, i.e. the reason this patch
> > >> couldn't be sent by email!
> > >>
> > >
> > > I apologize for the severity of this delay, but I am finally getting
> > > back to this patch set. I've rebased and am going through the various
> > > comments to implement suggested feedback. Please bear with me by
> > > re-reading your email above and help me understand if there is a
> > > resolution to the issue that Ian brought up: Namely, is there going to
> > > be a major problem with accepting this patch with its .csv files that
> > > naturally have very long lines?
> >
> > Yes, I think it's still a problem.
> >
> > > The reason why I picked using .csv files is stated in the original
> > > commit message: (1) enables easier long-term maintenance, (2) is an
> > > ascii format for textual comparisions, (3) allows direct comparison to
> > > hardware documentation.
> >
> > Perhaps an intermediate format could be used that: (1) is email and
> > patch friendly, (2) is well-supported by scripting languages, and (3)
> > can be transliterated to and from your CSV format easily enough. I was
> > thinking that JSON might be a suitable candidate for that.
> >
>
> That is an interesting idea--having a well-supported format for
> scripting would make this certainly possible. If I were to go this
> route, should I include two scripts (one to create CSV file to edit and
> another to convert back to JSON) to ease the maintenance?
>
> I could take that one step further and suggest an XML format with an XML
> schema to validate value types (although I personally dislike reading
> XML and am not sure I'd like to create a schema at this point).
>
Ok, so after playing around with this a bit, trying a JSON format and
converters, I've arrived at the following solution that I think can be
acceptable: By slightly rearranging the data and creating some tools
for conversion, I can now store the data as the authoritative source in
c structures in c-files.
I have created tools to read this information to re-create the csv
spreadsheets to allow for visual comparison with information from NI-MAX
and other tools to convert new csv content back to c-files. These tools
are comprised of (1) c-program and (3) python scripts. None of these
tools or other scripting impact the kernel build as the content is
already stored in c source files.
This new development obviates the need to introduce Python/Perl/JSON
content into the kernel build as we discussed in the thread of [PATCH
04/15]. This also removes the issue of having very long lines within
patch files for this content. I think this is the best approach.
I plan to finish re-implementing my patches with this change, testing,
and re-submitting. Feel free to send any comments in the interim...
More information about the devel
mailing list