arch / x86 / include / asm / unistd.h против include / asm-generic / unistd.h

В чем разница между этими двумя файлами? Я не могу этого понять. Я должен отметить, что первый файл должен бытьarch/x86/include/asm/unistd_32.h (или и_64.h). Вот быстрый предварительный просмотр того, что они содержат:

arch/x86/include/asm/unistd.h:

#ifndef _ASM_X86_UNISTD_32_H
#define _ASM_X86_UNISTD_32_H

/*
 * This file contains the system call numbers.
 */

#define __NR_restart_syscall      0
#define __NR_exit         1
#define __NR_fork         2
#define __NR_read         3
#define __NR_write        4
#define __NR_open         5
#define __NR_close        6
#define __NR_waitpid          7
#define __NR_creat        8
#define __NR_link         9
#define __NR_unlink      10
#define __NR_execve      11
#define __NR_chdir       12
#define __NR_time        13
#define __NR_mknod       14
#define __NR_chmod       15
#define __NR_lchown      16
#define __NR_break       17
#define __NR_oldstat         18
#define __NR_lseek       19
#define __NR_getpid      20
#define __NR_mount       21
#define __NR_umount      22

include/asm-generic/unistd.h

#if !defined(_ASM_GENERIC_UNISTD_H) || defined(__SYSCALL)
#define _ASM_GENERIC_UNISTD_H

#include <asm/bitsperlong.h>

/*
 * This file contains the system call numbers, based on the
 * layout of the x86-64 architecture, which embeds the
 * pointer to the syscall in the table.
 *
 * As a basic principle, no duplication of functionality
 * should be added, e.g. we don't use lseek when llseek
 * is present. New architectures should use this file
 * and implement the less feature-full calls in user space.
 */

#ifndef __SYSCALL
#define __SYSCALL(x, y)
#endif

#if __BITS_PER_LONG == 32
#define __SC_3264(_nr, _32, _64) __SYSCALL(_nr, _32)
#else
#define __SC_3264(_nr, _32, _64) __SYSCALL(_nr, _64)
#endif

#define __NR_io_setup 0
__SYSCALL(__NR_io_setup, sys_io_setup)

#define __NR_io_destroy 1
__SYSCALL(__NR_io_destroy, sys_io_destroy)

#define __NR_io_submit 2
__SYSCALL(__NR_io_submit, sys_io_submit)

#define __NR_io_cancel 3
__SYSCALL(__NR_io_cancel, sys_io_cancel)

#define __NR_io_getevents 4
__SYSCALL(__NR_io_getevents, sys_io_getevents)

/* fs/xattr.c */

#define __NR_setxattr 5
__SYSCALL(__NR_setxattr, sys_setxattr)

#define __NR_lsetxattr 6
__SYSCALL(__NR_lsetxattr, sys_lsetxattr)

#define __NR_fsetxattr 7
__SYSCALL(__NR_fsetxattr, sys_fsetxattr)

#define __NR_getxattr 8
__SYSCALL(__NR_getxattr, sys_getxattr)

#define __NR_lgetxattr 9
__SYSCALL(__NR_lgetxattr, sys_lgetxattr)

#define __NR_fgetxattr 10
__SYSCALL(__NR_fgetxattr, sys_fgetxattr)

#define __NR_listxattr 11
__SYSCALL(__NR_listxattr, sys_listxattr)

#define __NR_llistxattr 12

Ответы на вопрос(1)

Решение Вопроса

но весьма распространено существование избыточных файлов, когда разработчики пытаются перейти от старых механизмов к новым. Ваш случай здесь выглядит очень похоже.

Если вы извлечете ядро 3.4, вы обнаружите, что и arch / x86 / include / asm / unistd_32.h, и arch / x86 / include / asm / unistd_64.h пропали. Вместо этого они генерируются с использованием arch / x86 / syscalls.

Извлеките последнее ядро (у меня работает стабильная версия 3.4.2) и выполните «git log --stat arch / x86 / include / asm», найдите unistd_64.h, unistd_32.h или unistd.h.

Я обнаружил, что следующий коммит может быть вам интересен. commit 303395ac3bf3e2cb488435537d416bc840438fcb

Я никогда раньше не касался системных вызовов, поэтому я бы не сказал слишком много. Журнал Git, как правило, сортирует запутанные файлы. Вы также можете попасть в make-файлы, если у вас это хорошо получается. (Нет, поэтому я полагаюсь на git log.)

Ваш ответ на вопрос