Linux Users

cancel
Showing results for 
Search instead for 
Did you mean: 

NI-KAL for 2.6.31+ Kernels

Which udev interface does (K)Ubuntu 10.04 use -- do you have /sbin/udevcontrol or /sbin/udevadm? If you have the latter, then the post-flight scripts for DAQmx Base will not install the udev rules. To manually install them, invoke (as root):

mkdir -p "/etc/udev/agents.d/usb"


rm -f /etc/udev/agents.d/usb/nimxb_*
scriptFiles="`cd /usr/local/natinst/nidaqmxbase/etc/hotplug/usb; find nimxb_* -maxdepth 0 -type f | grep -v usermap | grep -v rules | awk '{printf "%s ", $0}'; echo ""`"
for i in $scriptFiles
do
   rm -f /etc/udev/agents.d/usb/$i
   ln -sf /usr/local/natinst/nidaqmxbase/etc/hotplug/usb/$i /etc/udev/agents.d/usb/$i
done


rm -f /etc/udev/rules.d/nimxb_*
rulesFiles="`cd /usr/local/natinst/nidaqmxbase/etc/hotplug/usb; find *.rules -maxdepth 0 -type f | awk '{printf "%s ", $0}'; echo ""`"
for i in $rulesFiles
do
   rm -f /etc/udev/rules.d/$i
   ln -sf /usr/local/natinst/nidaqmxbase/etc/hotplug/usb/$i /etc/udev/rules.d/$i
done

/sbin/udevadm control --stop-exec-queue
/sbin/udevadm control --reload-rules
/sbin/udevadm control --start-exec-queue

Joe FriedChicken

Joe Friedchicken
NI Configuration Based Software
Get with your fellow OS users
[ Linux ] [ macOS ]
Principal Software Engineer :: Configuration Based Software
Senior Software Engineer :: Multifunction Instruments Applications Group (until May 2018)
Software Engineer :: Measurements RLP Group (until Mar 2014)
Applications Engineer :: High Speed Product Group (until Sep 2008)
0 Kudos
Message 41 of 49
(1,017 Views)

Thanks for the help. My USB6210 is working now.

After running Joe's script I still had to 'sudo /etc/init.d/nipal start' to get it to work.

0 Kudos
Message 42 of 49
(1,017 Views)

That last piece sounds like the start-up/shut-down scripts aren't being called. Check your /etc/init.d links (or Ubuntu equivalent) for nipal.

Joe Friedchicken
NI Configuration Based Software
Get with your fellow OS users
[ Linux ] [ macOS ]
Principal Software Engineer :: Configuration Based Software
Senior Software Engineer :: Multifunction Instruments Applications Group (until May 2018)
Software Engineer :: Measurements RLP Group (until Mar 2014)
Applications Engineer :: High Speed Product Group (until Sep 2008)
0 Kudos
Message 43 of 49
(1,017 Views)

2-Making software does cost money. The Linux customers community takes it as granted that software must be free.

We - the community - also write the free software.

 

This cannot be true, because software authors must eat etc... "Who pays for it" is a heavy issue.

An IIO driver (assuming precise specs are available) usually takes a few weeks for a seasoned kernel hacker. (yes: I am one - I'm earning my coins that way)

 

but Dell has recently patronized such an order from Conexant/Linuxant for one specific kernel: the corresponding HSF package can be downloaded for free from the Dell support site. I did not investigate, but probably Dell must have delivered a large order of Linux-preinstalled machines.

Vendor OOT modules are usually crap - especially binary-only ones (never work reliably).

The correct way is working with the community and bringing them into mainline.

 

6-When it works (often but for infrequent models it does not - with the special case of Agere, widely spread, works poorly), the way it works could perhaps be extended to NI drivers. It completely relies on the identification of the smallest core of driver software which contains classified information

What information could be in some register sets, valuable enough for keeping it closed - and therefore the product itself pretty much unusable on Linux ?

NI could have made millon deals with my clients. But they didn't, exactly due to lack of free drivers or specs.

 

(Linux freaks, please, abstain from blaming people who try to eat daily).

I do eat daily. And I earn my money with - guess what - Linux software, including kernel drivers.

NI folks probably don't need to get more money, as they turned away from millon sales w/ my clients alone.

 

7-Bottom line: there is no free lunch, asking for and screaming is easy, but yields no progress, and a sane collaboration with NI could solve the problem

I tried collaborating w/ NI. They refused. So they didn't get the million deals. Period.

 

if kernel independent driver cores can be identified as it works with winmodems.

Kernel independent drivers ? Technically ridiculous (except for some rare cases, which can be supported entirely from userland). Kernel drivers are naturally depending on the kernel. And on Linux, they're integral part of the kernel, not separate programs or libraries.

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 44 of 49
(1,006 Views)

@rolfk wrote:

Did you pay for the driver as it is now or the full open source kernel driver, that NI never has promissed to do? Would you be willing to pay an extra license fee for such a driver, maybe even on a per installation base?

Developing an IIO driver takes a few weeks. Less than the anual spendings for toilet paper.

(yes: I'm earning my money with such things).

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 45 of 49
(1,006 Views)

@marvin24 wrote:

I definitely hope that they will drop the proprietary kernel stuff. On the other hand, I think they can't do this anymore as there are customers who bought devices/drivers from NI.

They can do both, and it isn't so hard. Developing a proper IIO or Comedi driver just takes a few weeks. And they could also add IIO/Comedi support to their proprietary userland stack.

 

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 46 of 49
(1,005 Views)

@Shawn B.

1.  If you want open source drivers you MUST ask for it.

 Tried it. Even had con-calls with a larger group @NI. Didn't help.

 

Yes, you can argue that making the drivers open source would solve all of the worlds problems and that should be enough motivation, but it is surprisingly difficult to convince people this is true.

From my experience, the decision makers don't even really understand the problem. And they even don't seem to understand, they've lost several millions by that. 

 

2.  National Instruments is a business, and like all good businesses they want to make money.  

Doesn't seem so. Turned away from million deals.

 

Will providing open source drivers, or even providing better support for more distributions make NI more money?

Yes, it would. 

 

Keep in mind that both developing open source drivers, or providing better support (more distributions etc) with the proprietary drivers requires more development effort and thus costs NI more money.

The proprietary drivers are a black hole - unmaintainable. Developing free drivers afresh takes a few weeks per device.

 

Additionally what does NI loose by NOT providing open source drivers or better Linux support? 

Millions.

 

If NI doesn't give you what you want will you get it from a competitor? 

Yes.

 

Or will you just use Windows, LabVIEW RT, or NI's current Linux offerings? 

Absolutely not. Completely unusable for us.

 

3.  Figuring out how much money NI makes by supporting Linux is surprisingly hard.  

I personally stopped a million deal.

 

NI can keep track of LabVIEW for Linux, but not all customers use LabVIEW.  

We don't use LV. Completely unusable for us. We're only interested in the HW.

 

Most hardware is not sold in Linux kits, so there is no way of knowing when a customer buys a piece of hardware and uses it on Linux. 

Could just ask ?

Or listen to customers when they're already taking to the product manager ?

 

If you want open source drivers why aren't you using Comedi?  

Because it doesn't support the HW we've been interested in. Due to lack of specs. Otherwise I would already have written my own drivers.

 

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 47 of 49
(1,003 Views)

@mhoogend

If only it were as simple as open source drivers being cheaper than proprietary.  For return on investment there is how much you invest, and how much money you make.  

Few weeks of development against million sales. Simple equation.

 

With limited man power there is still the question of will I get more return on investment on Linux or on other products. 

Right, they really lack manpower (told it to me in a call). They could just hire one of us (kernel hackers) - but this billion doller company can't afford that. So, no million deal with my clients.

 

Others have posed the question of essentially risk to the business by exposing how things work under the hood.

I highly doubt that. A few register sets don't tell anything useful about the really tricky parts, eg. the analog stuff.

 

There is varying opinion on this, but I will guarantee you that any closed source software has investments that a corporation would like to protect since they paid for their development. 

The software, maybe. But we're not interested in their software - we just want the interface specs of the hardware, so we can write proper drivers.

 

Some of those markets are getting some rumblings of Linux but that has continued to be an exception rather than a trend. 

No idea about their target market. But in the area of industrial automation (especially IOT context) Linux is very present.

 

A company is still going to go where it knows it can find money.  In particular in tight times of recession (like the last year) companies will focus on where they can make the most money and avoid additional risk.

A few month of work is a risk for a billion dollar company ? Seriously ?

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 48 of 49
(1,003 Views)

It's not about using a hal/kal - this makes cross plattform development easier and cheaper, 

No, it doesn't. Cross platform kernel driverrs are a ridiculous idea to begin with. We all see the result.

 

 others do this too and it is accepted by the community.

Can you name one kernel driver that does this and went anywhere near mainline ?

 

It's about mixing proprietary code with GPL code in kernel space (and not only kal does this, but also a lot of ni drivers/infrastructure), which is by the way legally questionable.

 It's also technically ridiculous. Just never works reliably.

 

Ok - enough whining, lets make a proposal: AFAIK, the Linux way of solving these problems is to provide a GPL licensed hal with the goal to be merged to the kernel (long term goal, may take years).

Not going to happen. The maintainers won't accept that crappy code.

Contribute to IIO or Comedia, and the chances are good. But don't try to even talk about such a silly "kernel abstraction" on lkml.

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 49 of 49
(1,004 Views)