2

これら 2 つのファイルの違いは何ですか? 私は本当にそれを得ることができません。最初のファイルはarch/x86/include/asm/unistd_32.h(または and _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 安定版が動作します)、「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 に答える