Re: Linux I/O Drivers for LabVIEW
Well, depending on the interface your hardware uses, there are various options. If it is a hardware board directly plugged into the PC, I believe you will have to provide some sort of kernel driver, as there is no way to access hardware directly from user space in a feasible way. If this hardware is however connected to the computer through a standard interface such as USB you can quite likely get away with accessing the according user space API to communicate through that interface.
As to your other questions:
1) No NI won't tell you how to create kernel device drivers. You can download DAQmx Base and get an idea what they did but you will have to come up with your own solution. NI is not in the business of teaching about kernel device drivers in general, and on Linux for sure. Their Linux support until now is a very delicate balance between protecting their own IP and complying with strict and continously increasing open source requirements from the Linux kernel developers. And kernel driver development, while not exactly magic, is a very specific technical ability that only a few people really can master. Last but not least it is not in their interest to support a competitor to their own hardware.
In the case of Linux kernel device drivers, the most easy path is to look at various types of the already present device drivers. Almost anything that gets distributed and residing inside the Linux kernel has to be more or less open source nowadays. So there are a lot of fully functional device drivers to look at and get an idea how they work. Writing your own still is a project that you should not take lightly. It costs a lot of time, coffee and nerves to get a kernel driver right, because every time something goes wrong, you are likely having to restart the whole system from scratch to be sure that you don't have corrupted kernel tables and what else messing with your whole system.
For Windows you would have to look at the DDKs, although the example drivers there, while they show how things are supposed to work, are usually very far from fully working drivers and other sources than the DDK are sparse and far in between.
2) Yes a kernel device driver while technically usually the hardest part to get really right (just working 99% of the time is really not enough for something that has the potential to take down your whole system very hard), is just the first step in the whole picture. After that you usually need a user space shared library that communicates with the kernel driver and provides an easy API for the applications to use your hardware. This API is what any application including LabVIEW written applications will use. Once you have the user space API you want to create a LabVIEW VI library that accesses this API through the Call Library Node. This is the only real LabVIEW specific part of the whole picture. All the rest up to this is simply necessary infrastructure to access hardware in a modern OS, be it from a C application, Python, or LabVIEW. And this applies to any modern OS, including Linux, Mac OS X, and Windows.