01-08-2011 09:29 AM
Perhaps we have to consider our options:
The long term solution is to again allow the NI GPIB USB driver to access the USB subsystem symbols in the kernel. If I understand the above info correctly, this can only be done via an open source driver or a user mode program. What NI strings do we have to pull to get this done?
Does somebody on this list has some knowledge about already existing open source kernel drivers which can be used with the NI GPIB USB device.
The short term solution, modifying the Linux kernel and the nikal source. Is this already tested or are we exploring here some uncharted territory. Can somebody on this list give me some clues, recipe to get started?
01-12-2011 09:13 AM
1. if you can contact your NI sales representative for your area, it would help. How much it'll help depends on the size of the sales opportunity
2. I found this through google: http://linux-gpib.sourceforge.net/ .. it looks like it supports our gpib usb device. I've never tried using this before though.
3. I don't think I can legally tell you the steps to circumvent the license limitation, but you can certainly start from nikal source code and experiment yourself.
Sorry, not much I can help with.
06-27-2018 10:39 AM
@jchrisjFor all of their purity of spirit, the USB subsystem maintainers make it more difficult for me to use Linux and, in fact, constrain some of the freedom that the O/S is about.
No, they actually *increase* the freedom of the users (along w/ stability and security) by prohibiting unmaintainable and unauditable proprietary crap code.
(Why shouldn't I be able to taint my own kernel, particularly for internal use? It is one thing to give me options to closed source software and entirely another to not allow me to use closed source code if I want to.)
You still can. But this code the must not be redistributed. That's the deal, and it always has been with the GPL. In exchange, you get a whole OS for free, including source code.