Howto Prepare Qtcreator for Linux Driver & Kernel Development

What IDE should I use for Linux module development?

Depending on what you want to do there are number to choose from. However I think the closest one to visual studio equivalent will be eclipse.

From the FAQ:

Eclipse is an open source community whose projects are focused on
building an extensible development platform, runtimes and application
frameworks for building, deploying and managing software across the
entire software lifecycle. Many people know us, and hopefully love us,
as a Java IDE but Eclipse is much more than a Java IDE.
The Eclipse open source community has over 200 open source projects.
These projects can be conceptually organized into seven different
"pillars" or categories:

Enterprise Development
Embedded and Device Development
Rich Client Platform
Rich Internet Applications
Application Frameworks
Application Lifecycle Management (ALM)
Service Oriented Architecture (SOA)

The Eclipse community is also supported by a large and vibrant ecosystem of major IT > > > solution providers, innovative start-ups, universities and research institutions and > individuals that extend, support and complement the Eclipse Platform.
One very exciting thing about Eclipse is that many people are using
Eclipse in ways that we have never imagined. The common thread is that
they are building innovative, industrial-strength software and want to
use great tools, frameworks and runtimes to make their job easier.

Is it possible to develop linux kernel module in CLion?

Yes, It is. But you will need to write make file for building kernel module.

Update 1:
I recommend QtCreator for writing linux kernel module.
See my manual

Update 2:
I also recommend eclipse cdt.
See eclipse manual about how to prepare it for linux kernel.

What does the I stand for in the QtCreator API for classes such as IRunConfigurationFactory, IFile, IProjectManager?

An uppercase "I" usually stands for "Interface". I'm not sure if that is the case here, but it would make sense to me.

CUDA, Qt creator and Mac

I managed to get your example running with a few minor corrections to your .pro file. If you or anyone else is still interested in a larger C++/CUDA/Qt example for Mac and Linux check this answer from a few months ago. Your particular situation (or at least what you've provided) doesn't require all the extra Qt frameworks and GUI setup so the .pro file stays pretty simple.

If you haven't already done so you should make sure you have the latest CUDA Mac drivers and check that some of the basic CUDA samples compile and run.
I'm currently using:

OSX Version 10.10.5
Qt 5.5.0
NVCC v7.5.17

I added a main method to the DP_GPU.cu file you provided and successfully ran the program using your .pro file with a few changes:

#CUDA_SOURCES += ../../Source/DT_GPU/DT_GPU.cu
CUDA_SOURCES += DT_GPU.cu # <-- same dir for this small example

CUDA_DIR = "/Developer/NVIDIA/CUDA-7.5"

SYSTEM_TYPE = 64            # '32' or '64', depending on your system
CUDA_ARCH = sm_21           # (tested with sm_30 on my comp) Type of CUDA architecture, for example 'compute_10', 'compute_11', 'sm_10'
NVCC_OPTIONS = --use_fast_math

# include paths
INCLUDEPATH += $$CUDA_DIR/include

# library directories
QMAKE_LIBDIR += $$CUDA_DIR/lib/

CUDA_OBJECTS_DIR = ./

# Add the necessary libraries
CUDA_LIBS = -lcudart # <-- changed this

# The following makes sure all path names (which often include spaces) are put between quotation marks
CUDA_INC = $$join(INCLUDEPATH,'" -I"','-I"','"')
#LIBS += $$join(CUDA_LIBS,'.so ', '', '.so') <-- didn't need this
LIBS += $$CUDA_LIBS # <-- needed this

# SPECIFY THE R PATH FOR NVCC (this caused me a lot of trouble before)
QMAKE_LFLAGS += -Wl,-rpath,$$CUDA_DIR/lib # <-- added this
NVCCFLAGS = -Xlinker -rpath,$$CUDA_DIR/lib # <-- and this

# Configuration of the Cuda compiler
CONFIG(debug, debug|release) {
    # Debug mode
    cuda_d.input = CUDA_SOURCES
    cuda_d.output = $$CUDA_OBJECTS_DIR/${QMAKE_FILE_BASE}_cuda.o
    cuda_d.commands = $$CUDA_DIR/bin/nvcc -D_DEBUG $$NVCC_OPTIONS $$CUDA_INC $$NVCC_LIBS --machine $$SYSTEM_TYPE -arch=$$CUDA_ARCH -c -o ${QMAKE_FILE_OUT} ${QMAKE_FILE_NAME}
    cuda_d.dependency_type = TYPE_C
    QMAKE_EXTRA_COMPILERS += cuda_d
}
else {
    # Release mode
    cuda.input = CUDA_SOURCES
    cuda.output = $$CUDA_OBJECTS_DIR/${QMAKE_FILE_BASE}_cuda.o
    cuda.commands = $$CUDA_DIR/bin/nvcc $$NVCC_OPTIONS $$CUDA_INC $$NVCC_LIBS --machine $$SYSTEM_TYPE -arch=$$CUDA_ARCH -c -o ${QMAKE_FILE_OUT} ${QMAKE_FILE_NAME}
    cuda.dependency_type = TYPE_C
    QMAKE_EXTRA_COMPILERS += cuda
}

And the DP_GPU.cu file with a main function and some minor changes:

#include <cuda.h>
#include <cuda_runtime.h>
#include <device_launch_parameters.h>
#include <stdio.h> // <-- added for 'printf'

__global__ void zero_GPU(double *l_p_array_gpu)
{
    int i = blockIdx.x * blockDim.x + threadIdx.x; // <-- in case you use more blocks
    printf("  %i: Hello World!\n", i);
    l_p_array_gpu[i] = 0.;
}

void zero(double *l_p_array, int a_numElements)
{
    double *l_p_array_gpu;

    int size = a_numElements * int(sizeof(double));

    cudaMalloc((void**) &l_p_array_gpu, size);

    cudaMemcpy(l_p_array_gpu, l_p_array, size, cudaMemcpyHostToDevice);

    // use one block with a_numElements threads
    zero_GPU<<<1, a_numElements>>>(l_p_array_gpu);

    cudaMemcpy(l_p_array, l_p_array_gpu, size, cudaMemcpyDeviceToHost);

    cudaFree(l_p_array_gpu);
}

// added a main function to run the program
int main(void)
{
    // host variables
    const int a_numElements = 5;
    double l_p_array[a_numElements];

    // run cuda function
    zero(l_p_array, a_numElements);

    // Print l_p_array
    printf("l_p_array: { ");
    for (int i = 0; i < a_numElements; ++i)
    {
        printf("%.2f ", l_p_array[i]);
    }
    printf("}\n");

    return 0;
}

Output:

  0: Hello World!
  1: Hello World!
  2: Hello World!
  3: Hello World!
  4: Hello World!
l_p_array: { 0.00 0.00 0.00 0.00 0.00 }

Once you get this working make sure to take some time checking out basic CUDA syntax and examples before you get too far in. Otherwise debugging is going to be a real hassle. Since I'm here though I figured I'd also let you know the CUDA kernel syntax is

kernel_function<<<block_size, thread_size>>>(args).

Your kernel call zero_GPU<<<size,1>>>(l_p_array_gpu) would actually create a bunch of blocks with a single thread when you actually want the opposite.

The following functions come from the CUDA samples and help determine how many threads and blocks you need for a given number of elements:

typedef unsigned int uint;

inline uint iDivUp(uint a, uint b)
{
    return (a % b != 0) ? (a / b + 1) : (a / b);
}

// compute grid and thread block size for a given number of elements
inline void computeGridSize(uint n, uint blockSize, uint &numBlocks, uint &numThreads)
{
    numThreads = min(blockSize, n);
    numBlocks = iDivUp(n, numThreads);
}

You can add them to the top of your .cu file or to a helper header file and use them to properly call kernel functions. If you wanted to use them in your DP_GPU.cu file you would just add:

// desired thread count (may change if there aren't enough elements)
dim3 threads(64);
// default block count (will also change based on number of elements)
dim3 blocks(1);
computeGridSize(a_numElements, threads.x, blocks.x, threads.x);

// run kernel
zero_GPU<<<blocks, threads>>>(l_p_array_gpu);

Anyway, got a little sidetracked but I hope this helps! Cheers!

How to do a clean rebuild of Linux kernel modules in Yocto?

Is there anything else that I should be cleaning before rebuilding the Linux kernel modules?

Yes. bitbake -c cleansstate make-mod-scripts

Any kernel module recipe will contain inherit module. This references meta/classes/module.bbclass which contains inherit module-base. This references meta/classes/module-base.bbclass which contains:

# We do the dependency this way because the output is not preserved
# in sstate, so we must force do_compile to run (once).
do_configure[depends] += "make-mod-scripts:do_compile"

The make-mod-scripts recipe (at meta/recipes-kernel/make-mod-scripts/make-mod-scripts.bb) adds files to the {build_dir}/tmp/work-shared/{MACHINE}/kernel-build-artifacts directory. (This is referenced as STAGING_KERNEL_BUILDDIR which is set in conf/bitbake.conf.)

Unfortunately, the kernel recipe will remove everything in the STAGING_KERNEL_BUILDDIR directory, since that directory is added to the do_shared_workdir[cleandirs] variable in meta/classes/kernel.bbclass. This ends up removing files that make-mod-scripts put there as well.