Блог

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

в этом случае

gcc подбирает <sched.h> заголовок, расположенный в обычном месте /usr/include/sched.h

в котором прототип функции определен следующим образом

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

в то время как версия ядра имеет это в /usr/src/linux-headers-2.6.35-23

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

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

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

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

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