Can Labview and NI-visa be installed on Mandriva 2010

[vhelmont]

Hello,

A few month's ago I asked our NI representative if it was already possible to install LabVIEW and NI-visa on a Mandriva 2010 environment. The NI representative announced me the bad news that Mandriva 2010 wasn't any longer supported by NI. He directed me to this forum for possible help. It seems that the new kernel used in Mandriva 2010 seems to be the problem. Is this problem already fixed and can LabVIEW be used on Mandriva 2010?

     Regards,

     Albert

[Bryan]

I'm not aware which kernel they included in Mandriva 2010, but I am currently running both DAQmx 8.0.1, daqmxbase 3.4.0, NI-VISA 5.0.0, and NI488.2 2.5.1 with the 2.6.33.4 kernel.  We routinely access hardware using all 4 components with no problems.  There was a slight glitch when 5.0.0 came out, but that was quickly remedied by the NI support crew.  

[anshuljain]

It is possible to run NI-VISA/NI-KAL under Mandriva 2010.0 Provided you stick to the official kernel, 2.6.31 and not any of the kernels from 2.6.33+. The reason for this is that in the new kernels the asm-offsets.h and other important files are placed in the ~/linux/generated folder instead of the ~/linux/ folder (maybe the paths are incorrect...). I've tested the install on MDV 2010.0 and it does work.

-Anshul

PS: You may want to reconsider Mandriva as a supported platform, as the distro is pretty much on its last legs and is fading away...fast. There's some hope, through a fork...Mageia. I moved all of my platforms to Ubuntu from Mandriva sometime ago...

[vhelmont]

Hello Anshuljain,

What version of NI-VISA and NI-488 did you use. I have Mandriva 2010 with kernel 2.6.31.14-server-1mnb installed. Labview 8.6 is working fine but I can't get my GPIB-USB-B interface up and running.

Regards,

Albert

[mhoogend]

vhelmont wrote:

Hello Anshuljain,

What version of NI-VISA and NI-488 did you use. I have Mandriva 2010 with kernel 2.6.31.14-server-1mnb installed. Labview 8.6 is working fine but I can't get my GPIB-USB-B interface up and running.

Regards,

Albert

With kernel 2.6.31 you aren't going to be able to use GPIB-USB-B with NI-488.  This is because the USB kernel symbols are restricted to GPL drivers.  You will need to use either ENET or PCI devices instead.

[vhelmont]

At the moment the GPIB-USB-B interface is the only way I have to communicate to measurement instruments via my portable. This "USB kernel symbols restrict to GPL drivers" thing, can it be overruled or fixed in some way? Is it there to stay in the new kernels?

[irwan]

AFAIK, it's there to stay, and won't ever be "fixed", since it's not a bug by linux kernel. It's a deliberate choice by USB subsystem maintainer.

There is a way to overide it on your own machine, but that involves changing and recompiling the kernel code to relicense those symbols locally as well as changing and recompiling nikal to use those symbols. I am not a lawyer, so I don't know the legality of that solution or what you can do with that.

Another option is to use the old kernel, one before they yanked out those syms from closed-source-drivers.

[vhelmont]

I am not an USB expert, can you explain a little bit what the problem is with this "USB kernel symbols restrict to GPL drivers" thing. Does this mean that people who want to use the GPIB-USB-B interface in there work environment to communicate with an instrument environment are stuck with an outdated Linux environment. Not really a promising thought. Do these USB subsystem maintainers know that there aren't many solutions on Linux to communicate via USB to GPIB devices. They also have to remember that it is for software designers a constant struggle to make the Linux environment acceptable for there management. Making it even more difficult to use the Linux environment in the industry and the scientific world will certainly not promote the use of Linux.

Changing and recompiling the kernel code is one thing, I am afraid that not many common people like to run that risk, but recompiling nikal is even another story, isn't that closed code?

[irwan]

USB subsystem maintainers deliberately decided that only GPL kernel drivers may access the USB subsystem symbols in the kernel. To be fair, they do allow user mode program to send USB packets to their USB devices. So they do give an alternative way to access the USB device.

Unfortunately, for us, NI GPIB USB driver was architected to be a closed source kernel driver. Thus it cease to work, since we can no longer access the USB subsystem in the kernel.

A couple of options:

* stick with an old kernel. Yes, not very promising, I agree.

* request that NI rearchitect USB driver to do it from user mode. Whether we do this is more of a business decision. I'm just a mere engineer.

* access the USB device through an open source kernel driver, either request NI to release one or use other open source driver (I don't know if one is already available)

* modify linux kernel and nikal for your own use. nikal's source is available to you, since it must be compiled on customer's machine to match linux kernel compilation. But I don't know the legality of this solution.

Whether it's difficult to use Linux really depends on your point of view. Some things are way easier in Linux compared to Windows. Some other things (like driver/open-source-ness) are more difficult on Linux to deal with. We're talking specifically on the impact of closed source kernel driver working on Linux, which is actively discouraged by the Linux community for various good reasons. Unfortunately, it doesn't quite align well with the way NI develop our drivers.

I'm sorry this is painful. Some of us Linux supporters do feel the same kind of pain internally. Unfortunately, like everything else, it all comes down to business priority as far as what we need to work on, since we have limited resources and gobs of products&platform we're trying to support. So please bear with us. I wish I have a better answer for you.

[jchrisj]

Where I work there are a set of manditory security controls that must be configured on any Windows-based computer on our network. The controls mandated for Linux systems are less specific and we have more ability to use sound judgement about the risks and rewards of specific controls.

The end result is that it is so difficult to put a windows-based data acquisition system on our network that we just tend not to do it because a lot of the mandated controls get in the way of using the system for its intended purpose. Those systems end up running Linux, so I've chosen the Linux version of LabVIEW for several of our experiments.

For 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. (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.)

The only long term solution I can see is for NI to either do a user mode USB driver or an open source driver. I chose to run labVIEW under Linux because it is an operating system that I can put on the network in a secure way and still do the work I need to do.