Где идентификаторы системных вызовов определены для архитектуры x86 в ядре Linux 5.0.1?

Я слежу за видеоуроком по системному программированию Linux.

Когда я дошел до раздела «как добавить свой собственный системный вызов Linux», инструктор показывает, что все идентификаторы системных вызовов (макросы, начинающиеся с __NR) присутствуют в arch / x86 / include / asm / unistd_32.h или unistd_64.h (в зависимости от цель).

Но в моем исходном коде (linux-5.0.1) я не вижу этих файлов, есть только один unistd.h, который не содержит идентификаторов системных вызовов. Были ли эти файлы перемещены в другое место или x86 теперь не имеет собственной таблицы системных вызовов.

Изменить: я загрузил последний исходный код ядра с kernel.org и пытаюсь его изменить. Я не могу найти файлы unistd_32.h и unistd_64.h в вышеупомянутом месте. Мне нужно что-то сделать в первую очередь?


person Community    schedule 14.03.2019    source источник


Ответы (1)


Arch Linux поставляется unistd_32.h и unistd_64.h в составе /usr/include/asm/. Просто посмотрите на эти заголовки, если вы не изменяете ядро ​​для добавления новых системных вызовов.

<asm/unistd.h> проверяет макросы, чтобы выяснить, включен ли он в 32-битный или 64-битный код (и проверяет наличие x32), и использует #include для извлечения правильного набора определений для цели.

В моей современной системе x86-64 Arch:

$ pacman -Fo /usr/include/asm/unistd*
usr/include/asm/unistd_32.h is owned by core/linux-api-headers 4.7-1
usr/include/asm/unistd_64.h is owned by core/linux-api-headers 4.7-1
usr/include/asm/unistd.h is owned by core/linux-api-headers 4.7-1
usr/include/asm/unistd_x32.h is owned by core/linux-api-headers 4.7-1

В самом исходном коде ядра, начиная с версии 3.3, unistd_32.h для использования в пользовательском пространстве построен из других файлов.

https://github.com/torvalds/linux/search?q=unistd_32.h&unscoped_q=unistd_32.h находит это в arch/x86/entry/syscalls/Makefile

$(uapi)/unistd_32.h: $(syscall32) $(syshdr)
    $(call if_changed,syshdr)

Таблицы системных вызовов определены в: arch/x86/entry/syscalls/syscall_32.tbl и .../syscall_64.tbl

https://github.com/torvalds/linux/tree/6f0d349d922ba44e4348a17a78ea51b7135965b1/arch/x86/entry/syscalls

Содержимое syscall_32.tbl выглядит так:

# some comments
0   i386    restart_syscall     sys_restart_syscall     __ia32_sys_restart_syscall
1   i386    exit            sys_exit            __ia32_sys_exit
2   i386    fork            sys_fork            __ia32_sys_fork
3   i386    read            sys_read            __ia32_sys_read
...
person Peter Cordes    schedule 14.03.2019
comment
Я загрузил последний исходный код ядра с kernel.org и пытаюсь его изменить. Я не могу найти файлы unistd_32.h и unistd_64.h в вышеупомянутом месте. Мне нужно что-то сделать в первую очередь? - person ; 14.03.2019
comment
@ShaikMuhammadYahiya: вы не изменяете их, вы изменяете syscall_32.tbl и 64.tbl, а затем запускаете make для генерации заголовков пользовательского пространства. Как сказано в моем ответе, они не являются частью исходного кода ядра напрямую. - person Peter Cordes; 14.03.2019
comment
@ShaikMuhammadYahiya Возможно, в вашем руководстве используется какая-то версия Linux старше 3.3. Действительно, в этих версиях unistd_32.h и unistd_64.h действительно существовали в каталогах, которые вы указали в вопросе. Вместо этого вы можете загрузить v3.2, если хотите следовать руководству. - person Hadi Brais; 14.03.2019
comment
@HadiBrais Да, вы правы, у инструктора Linux-2.6.32.7. Но я бы хотел получить последнюю версию ядра Linux, верно? Что вы предлагаете, я делаю? - person ; 15.03.2019
comment
@PeterCordes Спасибо, похоже, есть другая версия ядра Linux, которую использует инструктор. - person ; 15.03.2019
comment
@ShaikMuhammadYahiya Лучше использовать 2.6.32.7, чтобы вы могли легко следовать руководству. Если это дает ответ на ваш вопрос, вы должны нажать на галочку под стрелками голосования, чтобы принять ответ. - person Hadi Brais; 15.03.2019
comment
@HadiBrais: IDK об использовании старой версии ядра. Да, вероятно, будут и другие различия, каждое из которых может стать камнем преткновения, но конечная цель - научиться обходиться с текущим Linux, а не давать себе 9 лет на то, чтобы наверстать упущенное. (Хотя, как только вы поймете некоторые основы, мне было тривиально разобраться в этом конкретном вопросе и ответе. Увидев его как цель в Makefile, я понял, что он был построен из чего-то другого, а не из самого исходного файла.) Если есть какие-то новые руководства. , найти его может быть лучше. - person Peter Cordes; 15.03.2019