Linux Users

Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.
Highlighted

NI-KAL for 2.6.31+ Kernels

Hi all,

Any idea on when NI will release an NI-KAL update for Kernels 2.6.31 and greater? There are significant changes been done in the newer kernels...an NI-KAL update would really help in using the latest versions of Opensuse, Mandriva, Fedora etc....

-Anshul

0 Kudos
Message 1 of 49
(20,567 Views)
48 REPLIES 48

Re: NI-KAL for 2.6.31+ Kernels

I would also like to know when NI-KAL will support 2.6.31 and newer kernels, specifically Mandriva. 

I tried to re-install NI-KAL on Mandriva 2009 w/ a real-time patched 2.6.31 kernel with no luck. The 2.6.27 kernel works, but it's real-time consistency is less than desirable even when I apply the RT-patch.

0 Kudos
Message 2 of 49
(2,401 Views)

Re: NI-KAL for 2.6.31+ Kernels

I don't know how others think about it, but I find the current situation extremely unsatisfying. It's not about using a hal/kal - this makes cross plattform development easier and cheaper, others do this too and it is accepted by the community. 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. Even Microsoft realized this and contributed their hypervisor to the linux kernel. NI is sitting in the same trap like Nvidia/ATI with their proprietary drivers causing lots of problems to their customers.

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). On the other hand, looking at the code, nikal seems to provide some memory mangement/locking functions, hardware access functions and driver registering. If the rest of the kernel space code NI uses would be included into the kernel, these layer would not be necessary anymore - so in a "clean" solution it could be killed anyway.

How would this "clean" solution look like? Provide open source drivers for your products! There are many examples how other vendors did it. These drivers can be simple and small. The complicated/secret stuff could be done in a user-space! library which interacts with NI software products. Checkout the Linux driver project at http://www.linuxdriverproject.org or help the Comedi project to include your hw drivers _and_ provide the user-space library to interact with Comedi.

How do you (customers) think about it?

Marvin

P.S. what's wrong with decibel.ni.com? In the past weeks, it is more or less luck to get a connection!

0 Kudos
Message 3 of 49
(2,401 Views)

Re: NI-KAL for 2.6.31+ Kernels

marvin,

Your suggestion would be perfect...in an ideal world, where Linux is king and GPL is the a widely and industry accepted license. I've spent a fair amount of time communicating with the maintainer of the Linux Driver Project (Greg Kroah Hartmann) and some NI folks. I cannot elaborate much on this public forum, but NI-KAL going the GPL way isnt happening anytime soon. Thats the word from NI, as far as I know. I would really like this scenario to change, however there are lots of corporate, technical issues which influence such decisons.

Anshul

0 Kudos
Message 4 of 49
(2,401 Views)

Re: NI-KAL for 2.6.31+ Kernels

Ditto here. Come on, NI... time marches on...

- Mike

0 Kudos
Message 5 of 49
(2,400 Views)

Re: NI-KAL for 2.6.31+ Kernels

For what it is worth, there are similitudes here with the handling of "winmodems by the "linmodem" group of volunteers.

Because I manage our web site http://linmodems.technion.ac.il since almost 9 years now, the following remarks come from experience, not just brainstorming

1-To save one or two dollars on the final cost of a PC by stripping off functions from the modem,, work done by hardware in the past has been dumped onto the CPU, to a variable number of extents by a variety of manufacturers.

2-Making software does cost money. The Linux customers community takes it as granted that software must be free. This cannot be true, because software authors must eat etc... "Who pays for it" is a heavy issue. "Academic freedom" is an important source, it "pays" my average two hours a day volunteering.

3-The few manufacturers of chips for winmodems are willing to supply drivers for Linux if a sufficiently large order is received from a modem or PC manufacturer. This does not happen often, 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.

4-With time, some standardization of hardware has emerged. It really started by saving another dollar or two by using the sound chip of the sound system without duplicating sound functions in the modem chip: this was possible thanks to a new local bus standard, AC'97, gradually replaced by HDA. A major very "smart" chipset manufacturer, which has unfortunately sold its analog modem activity to somebody less smart, closed their eyes

on the fact that with the same AC'97 bus, their driver could serve any other AC'97 modem chipset if the CODEC component documentation is available (if interested see   http://en.wikipedia.org/wiki/AC%2797 ). This of course depends on the good will of the CODEC manufacturer. Thw Linux ALSA group of volunteers has then extended the ALSA "standard" to the modem. This replaces the possibly copyrighted commercial wrappers. THIS IS IMPORTANT FOR NI POLICY MAKERS: this approach does remove from you the burden of interfacing the core of your devices with the multitude of Operating Systems which crowds want you to support. Your industrial secrets are maintained, the core is protected, the burden is dumped onto the community of users.

5-With the multiplication of Linux distributions and the rate at which new kernels emerge, maintaining a library of drivers is a formidable task for a group of volunteers which hardly counts 10 people. Just browse through http://linmodems.technion.ac.il/packages

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 (Linux freaks, please, abstain from blaming people who try to eat daily). NI probably uses no more than a handful of such cores each associated with a chipset. Then a group of volunteers can learn a current wrapper for each supported core and maintain it for new kernels. One or two packagers can then prepare installers for a number of supported platforms/distros, perhaps even Ubuntu which I do not like but whose success must be recognized.

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 if kernel independent driver cores can be identified as it works with winmodems.

8-And you know, people, there is nothing as rewarding as a user giving notice that thanks to your work, her/his device is running. It even happens, from time to time, that somebody says "thank you".

Think about that too, NI people who may have read my prose so far.

Jacques

0 Kudos
Message 6 of 49
(2,401 Views)

Re: NI-KAL for 2.6.31+ Kernels

Who's asking for a free lunch? I'm paying real money for LabView and annual maintenance.

- Mike

0 Kudos
Message 7 of 49
(2,401 Views)

Re: NI-KAL for 2.6.31+ Kernels

Mike,

Let's not dive into a sterile argument.

Solution 1: hire a lawyer to check if your maintenance contract covers kernel updates. within a clear delay after kernel release.

Solution 2: try to collaborate with NI to do-it-yourself

Solution 2 works for winmodems since more than 10 years.

Jacques

0 Kudos
Message 8 of 49
(2,401 Views)

Re: NI-KAL for 2.6.31+ Kernels

Your suggestion would be perfect...in an ideal world, where Linux is
king and GPL is the a widely and industry accepted license. I've spent
a fair amount of time communicating with the maintainer of the Linux
Driver Project (Greg Kroah Hartmann) and some NI folks. I cannot
elaborate much on this public forum, but NI-KAL going the GPL way isnt
happening anytime soon.

I wouldn't give up so fast. Basicly, NI wants to sell hardware and software. For some reasons, they decided to support Linux (maybe because of the 7% of users yes - I know these numbers are not representive), so there must have been some customer demand for it. So now let's go one step further and demand open source drivers (and an open API). I know this may be harder to accomplish, but it is not impossible giving the possible advantages also for NI (e.g. easier porting to new kernels, bug fix contribution by the communite). In my opinion, it's just a matter of pressure on the management. As an example, some years ago NI payed a NI-developer to add limited hw support to Comedi, so there are people upstairs who are willing to support OSS. As I said, just a matter of customer pressure.

0 Kudos
Message 9 of 49
(2,401 Views)

Re: NI-KAL for 2.6.31+ Kernels

For whatit is worth, there are similitudes here with the handling of "winmodems by the "linmodem" group of volunteers.

Because I manage our web site http://linmodems.technion.ac.il since almost 9 years now, the following remarks come from experience, not just brainstorming

1-To save
one or two dollars on the final cost of a PC by stripping off functions
from the modem,, work done by hardware in the past has been dumped onto
the CPU, to a variable number of extents by a variety of manufacturers.

I'm not sure which NI-hw requires firmware, but uploading it is allready used by a lot of Linux drivers (scsi, graphics, scanners, ...). The firmware files can be extracted out of drivers anyway, so there is no secret to hide here.

2-Making software does cost money. The Linux customers community takes
it as granted that software must be free. This cannot be true, because
software authors must eat etc... "Who pays for it" is a heavy issue.
"Academic freedom" is an important source, it "pays" my average two
hours a day volunteering.

Wait - I paid for my hw, I also paid for the windows drivers I don't use (but ok) and I also paid for the Linux drivers. So this software is already paid, because it is bought with the hardware.

3-The few manufacturers of chips for winmodems are willing to supply
drivers for Linux if a sufficiently large order is received from a
modem or PC manufacturer. This does not happen often, 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.

Yes - this is a good example how customer pressure (from Dell) can force change (see my previous post). There is also another issue which is always neglected: If Dells sells PCs with Linux OS (as they do with Ubuntu), then they are responsible for delivering drivers and are also responsible that these drivers are legal. Just delivering binary blob puts them into the danger of being sued.

4-With time, some standardization of hardware has emerged. It really
started by saving another dollar or two by using the sound chip of the
sound system without duplicating sound functions in the modem chip:
this was possible thanks to a new local bus standard, AC'97, gradually
replaced by HDA. A major very "smart" chipset manufacturer, which has
unfortunately sold its analog modem activity to somebody less smart,
closed their eyes on the fact that with the same AC'97 bus, their driver could
serve any other AC'97 modem chipset if the CODEC component
documentation is available (if interested
see http://en.wikipedia.org/wiki/AC%2797
). This of course depends on the good will of the CODEC manufacturer.
Thw Linux ALSA group of volunteers has then
extended the ALSA
"standard" to the modem. This replaces the possibly copyrighted
commercial wrappers. THIS IS IMPORTANT FOR NI POLICY MAKERS: thi
s
approach does remove from you the burden of interfacing the core of
your devices with the multitude of Operating Systems which crowds want
you to support.

Your industrial secrets are maintained, the core is
protected, the burden is dumped onto the community of users.

Well, in my opinion sound cards are a bad example for so called "standards" (see the hda driver and the 5x more source lines of patches for each vendor). Nevertheless, HW suppliers can take advantage of a good maintained subsystem like alsa, ata or wifi (just to name a few). This reduces the lines of code required for hw drivers, but you also allow competating companies the same advantage. But at the end, this will push the platform as a whole and you will sell more.

5-With the multiplication of Linux distributions and the rate
at which new kernels emerge, maintaining a library of drivers is a
formidable task for a group of volunteers
which hardly counts 10
people. Just browse through
http://linmodems.technion.ac.il/packages

Eh - I take this as a "PRO"

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 (Linux freaks, please, abstain from blaming
people who try to eat daily). NI probably uses no more than a handful
of such cores each associated with a chipset. Then a group of
volunteers can learn a current wrapper for each supported core and
maintain it for new kernels. One or two packagers can then prepare
installers for a number of supported platforms/distros, perhaps even
Ubuntu which I do not like but whose success must be recognized.

I don't think the communication with the hw is a secret. Look at the Comedi drivers in staging. I count 21 drivers supporting NI hardware (all pci) using the same core (partly donated from NI). NI itself distributes software for accessing their hw on low level.  The main problem I see is the man power because - as you allready mentioned - people need to eat and the uses of NI hw don't want to waiste their time by coding drivers. So this has to be done by NI and I think I paid for it.

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 if kernel independent driver cores can be identified
as it works with winmodems.

I think this is wrong - asking leads to demand (important for management) and is the way to go (and the subject of this thread). This stands not in contrast to a kernel developer collaboration with NI. Both is needed.

8-And you know, people, there is nothing as rewarding as a user giving
notice that thanks to your work, her/his device is running. It even
happens, from time to time, that somebody says "thank you".

I didn't mentioned the NI Linux developers on purpose. They are the least responsible for the situation. To repeat it, it is our responsibility to hammer the support lines in the hope it will creep to the management level. So in the case anyone of them is reading this thread, take a look at http://www.itpro.co.uk/606360/free-linux-driver-development for example.

Marvin

0 Kudos
Message 10 of 49
(2,401 Views)
Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.