NI-KAL in SuSE Linux 11.4

[DiBosco]

Just bumping this, can anyone answer my question that I'm referring to in what anshuljain talked about in the last post of page one please? I am sure that if this works in Suse 11.4, it will work in other latrer distributions! Thanks a lot.

[anshuljain]

I wasn't exactly clear in my last post on copying some files from the include/generated folder to include/linux folder. I've spent the last few months in Windoze hell which kept me away from Linux land

The include/generated folder is where asm-offsets.h, autoconf.h, bounds.h & utsrelease.h files reside. In the case of openSUSE and Mandriva/Mageia (and almost all standard Linux distros), they're in the /usr/src/linux-<kernel version> folder. If you have a fully updated openSUSE 11.4 install, the folder would be:- /usr/src/linux-2.6.37.6-0.7/include/generated folder.

To get NI-KAL working on openSUSE:-

1. Install kernel-source and kernel-syms

2. Run the preparatory steps mentioned in the installation notes under the openSUSE section, like getting zcat /boot/..., make cloneconfig and make modules_prepare

3. Copy all the files in the /usr/src/linux-2.6.37.6-0.7/include/generated folder to /usr/src/linux-2.6.37.6-0.7/include/linux folder.

4. Now, run the INSTALL script.

5. Add the line vmalloc=256M in /boot/grub/menu.lst

6. Reboot.

You should have NI-VISA working now. Attached is a screenshot of visaconf working under my openSUSE 11.4 install and also the location of the include/generated folder

[DiBosco]

You beaut! I didn't need the vmalloc=256M, but did need the mem=4096M on boot. Also, I copied the patch of nical.c on page 1 of this thread to overwrite the existing /usr/local/natinst/nikal/src/nikcal/nikal.c. Needed the source, but didn't need to do anything in your step 2. This all now works on Mandriva 2010.2 and I'm willing to bet will work on Mageia and Mandriva 2011. Thanks very much for the help.

This is with the caveat that only LAN works.

Also, I can talk to a TTI PSU with this.

Thanks again, much appreciated.

[metux]

---

@COPeter wrote:

If not soon then LabJack will be getting a pretty big order and all of the NI6008s I have will be retired.

Thanks for the hint, I'll have a closer look at them.

As things stand, can't use NI products for our industrial diagnostic boxes, due to practically absent drivers (note: proprietary drivers are just completely unusable industrial purposes).

NI could just publish the necessary specs, so we could develop our own drivers and bring them to mainline. But it seems they don't wanna sell their devices for Linux users.

I realize that you folks want to sell LabView, but there are a lot of developers who just need simple data acquisition and control.  

And they also should understand that some applications need a real operating system, not just some soft-PLC.

[metux]

---

@irwan wrote:

I apologize for the situation guys. We know that Linux support is painful for our customers. 

Because you folks make it so! Just publish the full driver source or at least the necessary specs, so we can develop our own and bring it to mainline.  

By the way: DAQ devices belong into the IIO framework - and drivers in general belong into the kernel - not userland!

Linux moves pretty fast, 

Not that fast, at least the subsystem that are needed here. And not a big deal once it's mainlined. Of course, OOT-drivers are painful - but it's never meant for productional uses. 

Oh, and blob modules never work reliably. Just forget that idea completely.

and we only have limited resources dedicated for Linux internally, 

You could easily buy in experts. In the long run much cheaper than working around the tons of problem w/ the current Russian Roulette approach. 

and we have other obligations and priorities. 

So, Linux users aren't welcomed as customers ?

Ok, then please remove all public statements suggesting Linux support, as the just isn't any serious one.

It's hard to keep up with Linux kernel changes. 

The only hard part is maintaining the silly gpl-condome and trying some "cross-platform driver". It's a dumb idea in the first place. Just properly use the existing Linux infrastructure (eg. IIO) as it's supposed to, then everything gets pretty easy.

And yes, we know that there are better ways to support Linux with open source drivers and such, but that also comes with other set of problems. Sigh. 

Which ones exactly ?

I still don't know when the next official KAL release containing those changes will be released. We still need to discuss it internally to figure it out. 

So, you don't even have a decent release management that allows quick bugfix releases ?

I could add a big rant on lots of other really weird things in your .rpm's, but I'll better stop here ...

[metux]

---

@irwan wrote:

NI-KAL doesn't support USB. All USB symbols in the kernel was marked as EXPORT_SYMBOL_GPL sometime back, thus we can no longer call them. I'm also not aware of NI installing anything under udev rules.

---

At least you're not breaking the license terms here (as you did in other places).

Actually, you can be glad that not all kernel symbols are gpl-only - yet.

[metux]

---

@Gòl·lum wrote:

This is what I get (after executing gpibexplorer)

pc6113:/home/joan # grep nikal /var/log/messages

Aug 23 10:51:11 pc6113 kernel: [  303.825096] nikal: module license 'Copyright (c) 2002-2011 National Instruments Corporation.  All Rights Reserved.  Any and all use of the copyrighted materials is subject to the then current terms and conditions of the applicable license agreement, which can be found at <http://www.ni.com/linux/>.' taints kernel.

Note that tainted kernel means NO SUPPORT.