Linux I/O Drivers for LabVIEW

[metux]

---

@rolfk

KAL is Kernel Abstraction Layer. This is in fact mostly a kernel driver that abstracts anything kernel related in a way,

This already is ridiculous on its own, as the kernel already IS the abstraction layer between HW and applicatons - that's what the whole concept is all about.

that the drivers that are above it can mostly use the same code base independant of the actual platform.

They can't. Platforms differ very much, especially in the kernel internals and driver subsystems. That's actually the primary difference between operating systems.

Anyways, this silly nikal is even completely written for x86 only, as they do not use the proper abstractions provided by the kernel and base on x86-specific assumptions.

So this driver handles the actual management of kernel memory, DMA, interrupt service configuration and handling, etc.

And it does a bad job w/ that. They don't even know how to properly use the DMA subsystem - otherwise they wouldn't ever get silly ideas like trying to use userland heap as DMA buffer.

The KAL driver had to be open sourced since the Linux kernel developers have defined various kernel APIs that a closed source driver may not call anymore without violating the GNU license.

These functions may also not be legally called by proprietary code through a wrapper.

Theoretically one could write one single generic KAL type driver and call it then from user space libraries. However such a driver would need to be very involved, since you do not want to do a kernel driver call for every register address access when setting up hardware. 

And it would be extremely dangerous for security and stability (just as proprietary drivers usually are).

Every translation from user space to kernel space is rather expensive in time, and if you need to program lets say 100 registers to prepare a certain operation, that would be very expensive if you would do it from user space and use one KAL driver call per register. 

It would make it easy to audit what that stuff is actually doing to the user's computer. But that's exactly what NI does NOT want. They wanna do whatever they want with the user's machine, w/o him being able to audit or control that. Yes: they wanna control over other people's machines - that's very invasive an hostile against their own customers.

Not to forget that you would have to do all the work again for every other application you write, such as Visual Basic, Python, LabVIEW, etc and each time use the environment specific methods to implement this.

If they would just invest a few weeks (per device) to write a proper IIO driver and submit it to mainline, all of that wouldn't be needed - the device would easily run with standard GNU/Linux tools, via standard interfaces.

But they chose to go the extremely complicated and expensive, because they're hostile against their users, and the Linux community. They even publically blame us, the Linux community, for their bad code not running the way they want, and not playing nanny for them !

[metux]

wrote:

KAL is not a driver per se. It's more of a framework on top of which our drivers are built. 

Not just that. It's also a glue layer that wraps some kernel functions that changed in the past, so NI folks don't need to recompile their proprietary kernel modules so often. Well, that's at least what they hoped - in reality it works horribly bad, practically unusable. (And, of course lots of completely redundant code for stuff that IIO already handles in a much better way)

Kernel-internals change very frequently. The Linux kernel was never designed for such things, all kernel modules should be part of the kernel tree, and have to be built for *exactly* the version (and the build configuration) it's supposed to be loaded into. NI just still refuse to learn how the Linux kernel works, insisting in their crappy ridiculous like a little child that's whining because it didn't get an ice cream.

By the way: the reason why USB devices aren't supported anymore is pretty simple:

The Linux kernel is released unter the GPL, which mandates that all derived work (which a driver, that naturally needs to attach to kernel-internal APIs, of course is) must also be released as GPL (or an explicitly compatible license). If you refuse to do so, you immediately loose all rights to use the GPL software. (yes! you'd be forbidden to use Linux anymore - corporation wide!)

Some subsystem maintainers just still *tolerate* those GPL violations (by corporations like NI, NVidia, etc) - meaning, they do not do any legal actions (eg. filing lawsuits or criminal charges). Others - like the USB maintainer - aren't so tolarant and express this by marking the subsystem's exported symbols as GPL-only. For those it is absolutely clear, that proprietary drivers using those symbols is really illegal.

NI is too snotty for publishing some specs (register sets, etc) for their products and blackmails their customers into using proprietary (and therefore technically completely broken) binary-only modules. That would be illegal for USB devices, so they just completely dropped Linux support for their USB devices. Leaving their customers alone, with unusable products.

It abstracts the kernel differences between various platforms. 

Which is pretty ridiculous. Drivers are naturally an integral part of the platform - the way driver infrastructures work (general architecture, interfaces, data structures) are a major point that defines that platform.

On many platforms, eg. Linux, for most types of devices, the drivers have to be in the kernel, especially when things like direct bus access or interrupts are involved. Linux has standardized driver APIs for many, many types of devices (eg. for DAQ devices, there is IIO). This is what makes the GNU/Linux ecosystem so extremely portable and easily maintainable - applications are independent of the actual hardware (the primary goal of driver stacks). Individual HW drivers are usually very small (only need to cope with the really hardware specific stuff), since the corresponding subsystems do all the rest.

Trying to "abstract away" these things just leads to *very* complicated, bloated, practically unmaintainable code, proprietary APIs (so, defeating the goal of the driver concept), bad performance. instability - in short: very bad quality.

We write as much of the platform-specific stuff as we can in the KAL layer (reimplementing it for each platform),

See above: there isn't much to 'reimplement', as 99% of the NI "driver" code is completely obsolete and useless. The kernel has everything needed for supporting DAQ devices. It only lacks the few LOC that do the actual talking to the hardware. And that part is really Linux specific, as it has to use the corresponding kernel-internal APIs (which, BTW, are subject to changes over time). Unless you wanna completely reinvent everything, force the users to rewrite their applications just for using NI hardware and deal with the horrors of deploying and maintaining NI "driver" stuff.

and that exposes a unified API and driver architecture across all platforms.

And *HIGHLY* specific to NI. Completely incompatible w/ anything else, including the Linux itself. The standard interface for DAQ devices on Linux (and some other Unixoid kernels) is IIO.

Those drivers still have a kernel component and a separate user mode component. 

Quite frankly: I really wonder why you need a device specific kernel *and* userland part.

The kernel is meant for handling all. (yes, there's an exception for very complex devices like GPUs, where much of the driver is in userland, but DAQ devices are quite trivial compared to GPUs). All it needs is a few hundred LOC of hw specific code, that just plugs into IIO.

DAQmxBase, by the way, is a totally separate driver which is built in LabVIEW itself using the VISA API. The DLL you use for DAQmxBase in a C application is actually a LV-built DLL (that is, a DLL written in LabVIEW). That may still be an option for you.

---

*FACEPALM* even worse.