разница в прототипе функции уровня ядра и прототипе функции уровня пользователя

Question

Я сделал некоторые изменения в функции sched_setschedule () ядра linux.я успешно перекомпилировал и собрал его.Теперь, когда я пытаюсь использовать sched_setschedule () в моей C-программе (используя gcc), я заметил, что заголовок, который выбирает gcc, полностью отличается от файла заголовка, который я модифицировал для компиляции ядра.

в этом случае

gcc получает файл sched.h из /usr/include/sched.h

, в котором прототип func определен следующим образом:

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

в то время как в версии ядра используется ядро ​​2.6.35.23

/ usr / src / linux-headers-2.6.35-23

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

как эти два заголовка связаны или сопоставлены друг с другом?Другими словами, как изменения в прототипе функции ядра каскадно возвращаются в библиотеку gcc (файлы заголовков)

Answer 1

Функции ядра не нравятся непосредственно к коду пользовательского пространства.Вместо этого есть толстый слой, который проходит через интерфейс системных вызовов.Это сделано с помощью glibc.Заголовок в /usr/include принадлежит заголовкам glibc.Кажется, вы пытаетесь расширить официальный интерфейс планировщика, однако это также потребует от вас изменения и / или расширения самого glibc, что, как я предполагаю, не было вашим первоначальным намерением.Кроме того, если вы когда-нибудь захотите передать этот модуль ядра кому-либо еще, другому человеку также потребуется заменить свою версию glibc, которая включает исполняемые файлы и / или заголовки времени компиляции.

Вы можетенапишите свою собственную версию системного вызова sched_setparam, вообще не зависящую от sched.h, см. man 2 syscall.

Альтернативный подход - расширить ядро, не изменяя существующие интерфейсы, а создавая новые.Существует множество ресурсов о том, как добавить новые файлы /proc или /sys и обернуть их в новые отдельные библиотеки.