jshowa

I was wondering if anyone could tell me how to include linux source headers into a C program. Right now the header files for my linux version are stored in /usr/src/linux-headers-2.6.28-15/include, but I've noticed that many sites have said they were located in /usr/src/linux or /usr/include/linux but I don't have a /usr/src/linux directory.

Paticularly, I was trying to find the task_struct definition which is supposedly located in sched.h. One site told me it was in /usr/include/linux which it was, however it didn't contain the definition of task_struct. Another site told me it was in /usr/src/linux but I had no such directory so I looked in /usr/src/linux-headers-2.6.28-15/include and there was another sched.h that contained the definition of task_struct. However, the site contained some code snippets that included the sched.h file in this manner

#include <linux/sched.h>

However, when I do this, it points me to the sched.h in my /usr/include directory which doesn't contain the task_struct definition. So am I suppose to include it like this?

#include </usr/src/linux-header-2.6.28-15/include>

Or am I suppose to make a symbolic link from /usr/src/linux to usr/src/linux-header-2.6.28-15/include? Or do I copy the headers from usr/src/linux-header-2.6.28-15/include to /usr/include/linux? I don't know, I'm confused, and if someone could clarify I would appreciate it.

By the way the site I was looking at was this one: Learning about Linux Processes LG #133

If you look at the 7th code listing, they include the header as linux/sched.h

tabstop

My basic suggestion is to see what your system thinks it is, by typing something like "man task_struct" (or maybe "apropos task_struct") and reading the documentation.

Having said that, usr/src/linux-headers-2.6.28-15/include is certainly a possible path, but it's not where I'm sort of expecting that to be. I'm assuming you installed the linux devel package or source package or whatever it's called and that's what you got? Are you not actually running 2.6.28-15 yourself? (If you had two different versions of the kernel running around, then it would make sense to have the versions in the path.)

Kennedy

You could also update your Linux Headers (this should be an RPM or whatever for most systems). If it is not, then look for Linux Headers -- these are sanitized Linux headers from the kernel -- not just a copy of the Linux kernel headers.

bithub

Create a symlink -- that's what everyone else does.

__________________
bit∙hub [bit-huhb] n. A source and destination for information.

MK27

You could do it any of those ways I guess -- altho I would NOT do the last one. Also, if the "default" sched.h doesn't contain the task_struct definition but it does use it, then it must include something which includes the definition from somewhere. That is not unusual and if it is the case you don't have to go any further -- try it. You need to find the file to look at the struct yourself, but probably you do not have to #include that file yourself -- it will be included by the default sched.h (just a hunch).

Otherwise, particularly if you are distributing this, you might want to cut and past the definition right in if there is some question about it not being present on a normal system.

__________________

Accuracy and integrity mean nothing if you don't make it past the censors...PYTHAGORAS

brewbuck

It's actually critical that you NOT replace the headers in /usr/include. These are the headers which glibc was compiled against. If you replace them, you may end up with broken binaries when you try to compile something.

Strictly, you are supposed to recompile glibc when you upgrade the kernel, although almost nobody ever does that, since the exposed kernel structures change only rarely.

The correct thing to do is to provide the path to the correct headers using the -I option to gcc.

__________________
"Congratulations on your purchase. To begin using your quantum computer, set the power switch to both off and on simultaneously." -- raftpeople@slashdot

MK27

I have never seen someone recommend that and I've been compiling kernels for a decade. Not in any documentation, and I'd be interested to see if you can find any material on the web that does.

What you are saying makes sense, but I think it is very theoretical; as you say, "no body actually does that...". Strictly, I think you should then recompile all the tools (gcc, etc) then recompile the kernel again, then recompile glibc again.

Just a comment.

__________________

Accuracy and integrity mean nothing if you don't make it past the censors...PYTHAGORAS

Kennedy

I think he means when one updates the kernel headers (which is COMPLETELY different than the Kernel). In fact, if you are doing the GlibC build you'll see in the text that the kernel headers implies that this kernel is the OLDEST that this system supports, not that it doesn't support any of the new kernels, just we won't go any older than this set of headers. Realistically, you can update your kernel headers (yes, inside /usr/include) with the new set -- probably without breaking anything since GlibC is independent of Linux -- and continue on your marry way just fine. Most of the kernel headers are provided for interface with ioctl() and other commands. These are completely dependent on which kernel is used. BUT, it is highly recommended to NEVER include /usr/src/linux/include as a search path for included files as these are NOT sanitized.