Here's the follow-up patch which introduces the prototypes for the new syscalls. There was also a typo in one of the new symbols. Do we really need the __NR_ia32_* macros? The userlevel on x86-64 should be bi-arch and provide the native ia32 unistd.h.
Signed-off-by: Ulrich Drepper <[email protected]>
diff --git a/include/asm-x86_64/ia32_unistd.h b/include/asm-x86_64/ia32_unistd.h
index e87cd83..9afc0c7 100644
--- a/include/asm-x86_64/ia32_unistd.h
+++ b/include/asm-x86_64/ia32_unistd.h
@@ -300,7 +300,7 @@
#define __NR_ia32_inotify_add_watch 292
#define __NR_ia32_inotify_rm_watch 293
#define __NR_ia32_migrate_pages 294
-#define __NR_ia32_opanat 295
+#define __NR_ia32_openat 295
#define __NR_ia32_mkdirat 296
#define __NR_ia32_mknodat 297
#define __NR_ia32_fchownat 298
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index e666d60..c0c894d 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -534,4 +534,35 @@ asmlinkage long sys_spu_run(int fd, __u3
asmlinkage long sys_spu_create(const char __user *name,
unsigned int flags, mode_t mode);
+asmlinkage long sys_mknodat(int dfd, const char __user * filename, int mode,
+ unsigned dev);
+asmlinkage long sys_mkdirat(int dfd, const char __user * pathname, int mode);
+asmlinkage long sys_unlinkat(int dfd, const char __user * pathname, int flag);
+asmlinkage long sys_symlinkat(const char __user * oldname,
+ int newdfd, const char __user * newname);
+asmlinkage long sys_linkat(int olddfd, const char __user *oldname,
+ int newdfd, const char __user *newname);
+asmlinkage long sys_renameat(int olddfd, const char __user * oldname,
+ int newdfd, const char __user * newname);
+asmlinkage long sys_futimesat(int dfd, char __user *filename,
+ struct timeval __user *utimes);
+asmlinkage long sys_faccessat(int dfd, const char __user *filename, int mode);
+asmlinkage long sys_fchmodat(int dfd, const char __user * filename,
+ mode_t mode);
+asmlinkage long sys_fchownat(int dfd, const char __user *filename, uid_t user,
+ gid_t group, int flag);
+asmlinkage long sys_openat(int dfd, const char __user *filename, int flags,
+ int mode);
+asmlinkage long sys_newfstatat(int dfd, char __user *filename,
+ struct stat __user *statbuf, int flag);
+asmlinkage long sys_readlinkat(int dfd, const char __user *path, char __user *buf,
+ int bufsiz);
+asmlinkage long compat_sys_futimesat(int dfd, char __user *filename,
+ struct compat_timeval __user *t);
+asmlinkage long compat_sys_newfstatat(int dfd, char __user * filename,
+ struct compat_stat __user *statbuf,
+ int flag);
+asmlinkage long +compat_sys_openat(int dfd, const char __user *filename,
+ int flags, int mode);
+
#endif
Ulrich Drepper <[email protected]> wrote:
>
> Do we really need the __NR_ia32_* macros? The userlevel on x86-64 should be bi-arch and provide the native ia32 unistd.h.
I'd have thought that x86 and x86_64 could source-level-share the syscall
table, yes. ppc manages to.
On Wed, 2006-01-18 at 20:37 -0800, Andrew Morton wrote:
> Ulrich Drepper <[email protected]> wrote:
> >
> > Do we really need the __NR_ia32_* macros? The userlevel on x86-64 should be bi-arch and provide the native ia32 unistd.h.
>
> I'd have thought that x86 and x86_64 could source-level-share the syscall
> table, yes. ppc manages to.
AMD64 renumbered all the syscalls for optimal cacheline usage or
something stupid like that. I suppose the x86 emulation on AMD64 kernels
could share the i386 table, but then _NR_foo will have a different value
depending on context, and that'll just get confusing.
--
Nicholas Miell <[email protected]>
Nicholas Miell wrote:
> AMD64 renumbered all the syscalls for optimal cacheline usage or
> something stupid like that. I suppose the x86 emulation on AMD64 kernels
> could share the i386 table, but then _NR_foo will have a different value
> depending on context, and that'll just get confusing.
Yes, the syscall numbers are quite different, especially because x86 has
all syscalls, even the obsolete ones.
But what I mean is that the __NR_ia32_* macros in
asm-x86-64/ia32_unistd.h aren't used anywhere in the kernel. And in
userland the asm-x86/unistd.h file is used when compiling x86 apps. At
least this is how the kernel headers for userlevel use should be set up.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
On Wed, 2006-01-18 at 22:07 -0800, Ulrich Drepper wrote:
> Nicholas Miell wrote:
> > AMD64 renumbered all the syscalls for optimal cacheline usage or
> > something stupid like that. I suppose the x86 emulation on AMD64 kernels
> > could share the i386 table, but then _NR_foo will have a different value
> > depending on context, and that'll just get confusing.
>
> Yes, the syscall numbers are quite different, especially because x86 has
> all syscalls, even the obsolete ones.
>
> But what I mean is that the __NR_ia32_* macros in
> asm-x86-64/ia32_unistd.h aren't used anywhere in the kernel. And in
> userland the asm-x86/unistd.h file is used when compiling x86 apps. At
> least this is how the kernel headers for userlevel use should be set up.
Ah, that makes sense. Actually, a few of them are used (sigreturn,
rt_sigreturn, and restart_syscall), but I suppose those could be defined
locally.
--
Nicholas Miell <[email protected]>