• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 52 subscribers
  • Views 4836 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

#include <linux/module.h> is showing as an unresolved inclusion even though make compiles succesfully

Christopher Grey
Intellectual 430 points

I'm trying to get myself setup to do kernel driver development. So I start where everybody does, writing the hello world kernel module. I did this 1st pointed at the Ubuntu Linux stuff. Then updated the makefile for cross-compiling the same driver code for a Beaglebone's Sitara AM-335x processor. After getting the makefile paths updated, I now have that working and runnable on the Beaglebone.

After importing the very simple project into Code Composer Studio v5.1, CCS indicates that the #include <linux/module.h> is an unresolved inclusion. I find that hard to believe since it makes just fine. However after searching through the SDK, I don't find a module.h anywhere in there. I recall the install also stuck something related to arm-arago-gnueabi- in my /usr directory, so I also did a search in there and didn't see anything. I suspect the module.h is somewhere on my machine, it's just in a folder I'm not looking in. So there's some detail I'm missing, and evidently CCS is missing it too about where to find it. Although if I search through the Linux source that Ubuntu is running (/usr/src/linux-headers-3.0.0-17/include/linux), there is a module.h file.

So in newbie explanation level detail, what's the deal with <linux/module.h> resolving when I run make, but not really existing when go look for it in my TI SDK installation folder (SDK 5.03.03)? And more importantly, how do I fix this in Code Composer so I can go back to trusting what it is telling me about the code I'm writing?

Once I get past the hello world phase of getting to module driver development, it's my intention to move onto some existing code that's been written but is very dated code that I suspect was written for Linux 2.4.x and needs to be updated to compile for a 2.6/3.x Linux kernel. But before I can make any headway there, I need to understand some fundamentals about how kernel modules are built that isn't being explained in any of the Google searches or in the documentation I'm reading.

  • 0
    Intellectual 430 points

    By the way, here's what my hello world kernel module code looks like....

    Makefile:

    obj-m += hello-1.o
    #    KERNELDIR ?= /lib/modules/$(shell uname -r)/build
        TOOLCHAIN ?= /home/cgrey/ti-sdk-am335x-evm-05.03.03.00
        KERNELDIR ?= $(TOOLCHAIN)/board-support/linux-am33x
        CROSS_COMPILER ?= $(TOOLCHAIN)/linux-devkit/bin
        PWD := $(shell pwd)
    all:
        $(MAKE) -C $(KERNELDIR) M=$(PWD) ARCH=arm CROSS_COMPILE=$(CROSS_COMPILER)/arm-arago-linux-gnueabi- modules

    clean:
        $(MAKE) -C $(KERNELDIR) M=$(PWD) clean

    And the C-code:

    /*  
     *  hello−1.c − The simplest kernel module.
     */
    #include <linux/module.h>       /* Needed by all modules */
    #include <linux/kernel.h>       /* Needed for KERN_INFO */
    int init_module(void)
    {
            printk(KERN_INFO "Hello world 1.\n");
            /*
             * A non 0 return means init_module failed; module can't be loaded.
             */
            return 0;
    }
    void cleanup_module(void)
    {
            printk(KERN_INFO "Goodbye world 1.\n");
    }


  • 0 in reply to Christopher Grey
    Intellectual 430 points

    Well after getting some sleep and looking at this differently, I see now I shouldn't trust the GUI for much. When I use the "find" command in the terminal, I see there is a module.h file in my SDK...lots of them in fact. And there is one right where there's supposed to be. So that solves that mystery and I feel like a total noob. 

    Knowing the file does exist, I'm assuming the only thing to do at this point is figure out how to get CCS to search into the includes folders that have these files. Since there are lots of .h file folders and subfolders, is there a way to tell CCS that you want to include a folder AND all of its subfolders in the indexing search for *.c/*.h files? If so, I'm not finding it. After adding the folder that will allow CCS to locate the module.h file, it now correctly shows the file as a known inclusion and lets me navigate to it via F3. However inside this file, there are references to other .h files that are in an /asm folder. For example, there's #include <asm/module.h> that CCS can't find. When I hit F3, it comes up and says it couldn't find the file in red at the bottom. The interesting thing is the file isn't underlined or identified as an unidentified inclusion. I'm assuming that's just a sign the indexer needs to run. Looking back at the find results of my original module.h search, I find that there are a number of asm/module.h files that look like they are for different platforms. Since I'm working with an ARM, I added that path to my project's includes. And now CCS seems to be working as I expect. I guess it was just late in the day yesterday and I wasn't seeing the forest for all the damn trees in the way.

    Now I'm having to tell CCS all this info manually. I'm assuming that the correct paths to look in are known by make thanks to already created makefiles that key off of the ARCH= choice. But my question at this point...is there a way I can get CCS to be more intelligent about "figuring out" the proper include paths for itself based on a make target I define in CCS? Or is that asking too much of CCS?