LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

How to create a Kernel Space driver

Our current driver is actually a user-space driver. After build, it generates a dll, same as a library. I have following questions:

1. Is there a way to create a Kernel-space driver?

2. If there is no Kernel-space driver, how can we change the priority of the interrupt service routine and DMA setup procedures in the user-space to reduce the latency caused by the interruptions from other threads?

0 Kudos
Message 1 of 9
(3,672 Views)

@ddcjz wrote:

Our current driver is actually a user-space driver. After build, it generates a dll, same as a library. I have following questions:

1. Is there a way to create a Kernel-space driver?

2. If there is no Kernel-space driver, how can we change the priority of the interrupt service routine and DMA setup procedures in the user-space to reduce the latency caused by the interruptions from other threads?


1) You'll have to install the Windows DDK in order to be able to develop kernel drivers and generally will need to use the DDK command line tools to compile and link such a driver. LabWINDOWS CVI is not a kernel driver development environment at all. You can't even do that with Microsoft Visual Studio really. You also need to write explicit code to work as kernel driver, with the correct IRP structures and everything. See https://msdn.microsoft.com/en-us/library/windows/hardware/ff553208(v=vs.85).aspx for a starting point. In general writing, and especially debugging kernel mode drivers is a completely different thing than writing user space applications. Expect a few weeks of learning the basics and getting used to all this before you can be really starting to do any serious work. And that is only if you are a very experienced C programmer.

2) A user space application or driver has no business of modifying DMA and interrupt configurations in the system. The necessary APIs to do so are all privileged and normally only accessible from a Ring 0 software module, which means a driver running inside the kernel itself. Messing with this in any way can completely blue screen your computer in a matter of seconds.

 

Rolf Kalbermatter
My Blog
Message 2 of 9
(3,625 Views)

Thank you for providing the insights.

We have Windows Kernel-space driver and NI real-time User-space driver. How can we port the Windows Kernel-space driver into the NI real-time environment? How can we modify the current NI real-time User-space driver into the NI real-time Kernel-space driver? Any documents for the guidance?

0 Kudos
Message 3 of 9
(3,593 Views)

@ddcjz wrote:

 

How can we port the Windows Kernel-space driver into the NI real-time environment?

You can't! Kernel drivers are VERY system dependent and there is no common driver development model for cross platform kernel drivers. A kernel driver is generally always an almost complete rewrite for every operating system.

Since NI Realtime is really a choice of three different very varying OSes too, it's also depending on for what NI Realtime you want this to work. 

There is NI ETS (Pharlap), VXWorks 6.3, and NI Linux Realtime. For ETS and VxWorks you need to buy the very expensive system development platform in order to write kernel mode drivers. For NI Linux realtime you can basically write a Linux kernel module, which can be done with GNU tools but is again a very different driver model than for Windows.

Rolf Kalbermatter
My Blog
0 Kudos
Message 4 of 9
(3,589 Views)

Thank you for the further information about the NI real time.

 

We have also VxWorks 6.x and Linux drivers. For VxWorks 6.3, any special BSP for the NI PXI-8119 machine? For Linux real-time, what Kernel version NI Linux Real-time uses?

0 Kudos
Message 5 of 9
(3,585 Views)

Sorry no idea about what specific BSP would be needed. But all VXWorks targets use a PPC CPU so that should give you an idea in which direction to look for. NI Linux Realtime kernel should be very easy to find out. I believe it is something like 3.6 but not really sure. It's definitely a 3.x version and not the newer 4.x baseline.

Rolf Kalbermatter
My Blog
0 Kudos
Message 6 of 9
(3,583 Views)

Great!

In our LabView OS options, we have Windows, ETS and Linux. Windows is to use the native Windows driver; ETS is the OS currently we have performance problem; Linux will be Linux 3.x driver. If we can switch to NI Linux real-time, is there anything special we need to do to port our existing Linux driver 3.x to NI Linux real-time?

0 Kudos
Message 7 of 9
(3,581 Views)

But according to this list, the NI-PXI 8119 is running PharLap ETS as realtime OS! And you can not use NI Linux RT on a PXI system so far and if that will be supported there won't be any backport to old hardware, only a new hardware.

Rolf Kalbermatter
My Blog
Message 8 of 9
(3,575 Views)

Good to know that.

So we have to live with ETS. But ETS driver is a user-space driver. We know that our Interrupt service routine and DMA setup procedure can be held up by a LabView application. It has performance problem. Is there any way to guarantee the interrupt service routine and DMA setup procedure without any interruption?

 

0 Kudos
Message 9 of 9
(3,567 Views)