Question

这两个文件有什么区别？我真的不明白。我应该提一下，第一个文件应该是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

Answer 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。

我发现以下提交可能对您有意义。提交303395ac3bf3e2cb488435537d416bc840438fcb

我以前从未接触过系统调用，所以我不想说太多。 git log通常是我如何理清混乱的文件。如果你擅长，你也可以进入makefile。（我不是，所以我依赖git log。）

arch / x86 / include / asm / unistd.h与include / asm-generic / unistd.h

1 个答案: