2

这两个文件有什么区别？我真的无法理解。我应该提到第一个文件应该是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
4

1 回答 1

2

我没有明确的答案，但是当开发人员试图从旧机制转移到新机制时，冗余文件的存在并不少见。你的情况看起来很相似。

如果你检查 3.4 内核，你会发现 arch/x86/include/asm/unistd_32.h 和 arch/x86/include/asm/unistd_64.h 都没有了。相反，它们是使用 arch/x86/syscalls 生成的。

检查最新的内核（3.4.2 stable 对我有用），然后执行“git log --stat arch/x86/include/asm”，搜索 unistd_64.h 或 unistd_32.h 或 unistd.h。

我发现以下提交可能会让您感兴趣。提交 303395ac3bf3e2cb488435537d416bc840438fcb

我以前从未接触过系统调用，所以我不想说太多。git log 通常是我整理令人困惑的文件的方式。如果你擅长它，你也可以进入 makefile。（我不是，所以我依赖 git log。）

于 2012-06-14T04:34:55.787 回答