Include kernel header files
 

I want to find the offset of a member of a structure within the kernel header file sched.h. (/usr/include/linux)
(i.e. I want to found out how many bytes the element 'tasks' is from the start of the task_struct which is declared in sched.h)

Is there a way I can do that?

My plan is to use the offsetof() function in C, but since sched.h is a kernel header file, I just inserting

does not work. It gives me a looong list of errors from the includes in sched.h.

Is there a way that I can do this?

(i am using Suse 10.1 with kernel 2.6.16.13-4

First, the easy part. offsetof is not a function, but rather a preprocessor macro. You can use it a few ways yourself:

1. #include <linux/stddef.h>
2. #define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
3. #define offsetof(TYPE,MEMBER) __builtin_offsetof(TYPE,MEMBER)

(Number 3 can only be used on compilers that implement the __builtin_offsetof operator such as gcc-4.x)


Now for the not-so-easy part, including a linux header file from userspace is useful mostly for getting the values of certain preprocessor macros. You can’t try to access anything in between “#ifdef __KERNEL__” and its corresponding “#endif” unless you are in kernel space. Generally, a distro will “sanitize” the kernel headers (i.e., removing those sections you can’t viably use) and put them in /usr/include/linux. As you can see in an unsanitized version of sched.h, struct task_struct is armored by #ifdef __KERNEL__/#endif (for various reasons). So you can’t do operations on a task_struct unless you are in kernelspace. As for the errors from including sched.h, that is odd. You might not have good, sanitized kernel headers, or you might be inadvertently using headers from your actual kernel source. If this is still puzzling you, can you give us some output from you attempt to compile such a file.

Hmmm... that could pose few problems...

Well, in short my code is the following:

the offsetof () macro isn't really the issue, because it worked when I used test data structs with it.
My problem is as you said, including sched.h to work on the task_struct.

The errors that I get, when I compile this with gcc 4.1.0
are the following:
and this is just a sample... it goes on to about 300 errors from the following files jiffies.h, nodemask.h, cpumask.h, bitmap.h ...these are only some of them, however all these h files that i get errors from are included in sched.h

I am using this version of sched.h

So, what you said about the kernel space, is there a way I can do that in my program? Do i have to #define something? or create some sort of makefile?
Or perhaps you can point me somewhere that explains to me how to do this?

I would also need to get this working to use the sizeof() on the struct page, as mentioned here i imagine...


Thanks

If you look at that version of sched.h, you see “#ifdef __KERNEL__” occurs on line 171 (with its corresponding “#endif” on line 1479), surrounding the definition of “struct task_struct” on line 696. So even if you didn’t have those errors, you still wouldn’t have access to the struct. It also appears that at the beginning, various files are included that shouldn’t be included (this has subsequently been fixed) such that one cannot sanely include “linux/sched.h” in a userspace program without the errors that you describe.

Look for code in np.

Here’s (rather simple) sample code that does what you want:

offset.c
Makefile
To run, just do something like:

Ah, the kernel modules... Yes, I should have known... what better way than to use Kernel space? :)


Though.... those caused me another branch of problems with the makefiles.
But i think its a small one actually....

When i create a makefile, I always get the same error...

I think it has something to do with the directories though...
Because the sched.h i need is in /usr/include/linux rather than
/usr/src/linux-2.6.16.13-4-obj/i386/default.

I actually have this problem with any kernel module i try... including those in the LKMPG tutorial...

I have never been well acquanted with makefiles, only what i know from tinkering with them here and there, and that wasn't that much...


thanks loads, your help is proving invaluble, seriously. I have been stuck on this problem for ages :)

My first question is this: do you have the buildtree for the kernel you are running? Perhaps you might elucidate the situation by posting the output of the following:
Without knowing the output of the previous commands, I will make a blind suggestion of changing one line in the Makefile: in line 2, change “build” to “source”. Alternatively, if you already know the kernel buildtree location, pass it to the make command (e.g., for me, I would say “KERNELDIR=/usr/src/linux-2.6.21 make” instead of “make”).
I sincerely doubt it. The headers in /usr/include/linux are santized for userspace. The kernel tree has its own headers (on which the aforementioned headers are based). Generally, these would reside in /lib/modules/`uname -r`/build/include/linux.

Also, I’m not too familiar with SUSE, so if anyone else knows how it manages kernels and their source/buildtrees, feel free to chime in.

If you haven’t already, see here and here for similar problems (and solutions).

I think you hit on the problem

Output from:
When i check in GUI, in /lib/modules/'uname -r'
the build directory only contains Module.symbers

and there is a source shortcut which has an invalid link :rolleyes:

That does not really bode well, does it?
If i'm not mistaken, source should link to /usr/src/'uname -r'

'uname -r' is actually 2.6.16.13-4-default, however /usr/src contains a direcory called 2.6.16.13-4-obj



also:
all these problems...this clearly does not desire to work!

It seems you don’t have the correct package(s) for building kernel modules. Here is a guide for doing kernel related stuff in SUSE (check specifically the section entitled “Building additional (external) modules”).
This is not necessarily true (in fact, that’s why we use “/lib/modules/`uname -r`/source” rather than “/usr/src/linux-`uname -r`”). Source is just a symlink to wherever you keep the kernel source. When people compile their own custom kernels, source and build often point to the same location (often somewhere in the $HOME directory). If you read the document I linked to, it explains the SUSE method of doing kernels (and the symlink naming scheme).
That’s very odd (not to have insmod on a functional desktop)…
The insmod utility is generally part of the module-init-utils package. It is in the same boat as modprobe and depmod (I think). So find out if you have module-init-utils installed and if you do, find out what files are contributed by the package (and where they’re located). Or perhaps the problem is your sudo is somehow trying to preserve $PATH. Try as root or with the full path (or add /sbin to your PATH).