Question

I did some of the modification in sched_setschedule() function of the linux kernel. successfully recompiled and build it. Now when i try to use sched_setschedule() in my C program (using gcc) i noticed that the header gcc is picking is completely different from the header file which i modified to compile the kernel.

in this case

gcc is picking up the <sched.h> header located in usual place /usr/include/sched.h

in which the func prototype is defined as below

extern int sched_setparam (__pid_t __pid, __const struct sched_param *__param)
     __THROW;

while the kernel version have it in /usr/src/linux-headers-2.6.35-23

extern int sched_setscheduler(struct task_struct *, int, struct sched_param *);

How these two header are related or mapped to each other? In other words how does change in kernel function prototype is cascaded back to gcc library (header files)?

Answer 1

Kernel functions don’t like directly to user-space code. Instead, there’s a thick layer that goes through the system call interface. This is done by glibc. The header in /usr/include belongs to the glibc headers. It seems that you are trying to extend the official scheduler interface, however that would also require you to modify and/or extend glibc itself, which I’m guessing wasn’t your original intention. Also, if you’d ever want to give this kernel module to anyone else, the other person would also need to replace his version of glibc which includes run-time binaries and/or compiler time headers.

You can write your own version of the sched_setparam system call without depending on sched.h at all, see man 2 syscall.

An alternative approach would be to extend the kernel without modifying existing interfaces, but instead creating new ones. There are handful of resources of how to add a new /proc or /sys files and wrap them up in new, separate libraries.