missing entries in fsys.S

missing entries in fsys.S

[Stephane Eranian]

[-- Attachment #1: Type: text/plain, Size: 286 bytes --]

Tony,

It appears that Linus's 2.6 git tree is missing some entryies in fsys.S.
I don't know abot your particular GIT tree. In any case, here is a patch
to fix this.

signed-off-by: <eranian@hpl.hp.com>

changelog:
	- add new system calls to fastsyscall table in fsys.S

-- 

-Stephane

[-- Attachment #2: fsys.diff --]
[-- Type: text/plain, Size: 1849 bytes --]

diff --git a/arch/ia64/kernel/fsys.S b/arch/ia64/kernel/fsys.S
--- a/arch/ia64/kernel/fsys.S
+++ b/arch/ia64/kernel/fsys.S
@@ -878,7 +878,50 @@ fsyscall_table:
 	data8 0				// timer_delete
 	data8 0				// clock_settime
 	data8 fsys_clock_gettime	// clock_gettime
-	#define __NR_syscall_last	1255
+	data8 0				// sys_clock_getres	// 1255
+	data8 0				// sys_clock_nanosleep
+	data8 0				// sys_fstatfs64
+	data8 0				// sys_statfs64
+	data8 0				// sys_mbind
+	data8 0				// sys_get_mempolicy	// 1260
+	data8 0				// sys_set_mempolicy
+	data8 0				// sys_mq_open
+	data8 0				// sys_mq_unlink
+	data8 0				// sys_mq_timedsend
+	data8 0				// sys_mq_timedreceive	// 1265
+	data8 0				// sys_mq_notify
+	data8 0				// sys_mq_getsetattr
+	data8 0				// sys_ni_syscall	// reserved for kexec_load
+	data8 0				// sys_ni_syscall	// reserved for vserver
+	data8 0				// sys_waitid		// 1270
+	data8 0				// sys_add_key
+	data8 0				// sys_request_key
+	data8 0				// sys_keyctl
+	data8 0				// sys_ioprio_set
+	data8 0				// sys_ioprio_get	// 1275
+	data8 0				// sys_ni_syscall
+	data8 0				// sys_inotify_init
+	data8 0				// sys_inotify_add_watch
+	data8 0				// sys_inotify_rm_watch
+	data8 0 			// sys_migrate_pages	// 1280
+	data8 0				// sys_openat
+	data8 0				// sys_mkdirat
+	data8 0				// sys_mknodat
+	data8 0				// sys_fchownat
+	data8 0				// sys_futimesat	// 1285
+	data8 0				// sys_newfstatat
+	data8 0				// sys_unlinkat
+	data8 0				// sys_renameat
+	data8 0				// sys_linkat
+	data8 0				// sys_symlinkat	// 1290
+	data8 0				// sys_readlinkat
+	data8 0				// sys_fchmodat
+	data8 0				// sys_faccessat
+	data8 0				// sys_ni_syscall	// reserved for pselect
+	data8 0				// sys_ni_syscall	// 1295 reserved for ppoll
+	data8 0				// sys_unshare
+
+	#define __NR_syscall_last	1297
 
 	.space 8*(NR_syscalls + 1024 - __NR_syscall_last), 0
 

RE: missing entries in fsys.S

[Chen, Kenneth W]

Stephane Eranian wrote on Wednesday, February 15, 2006 6:34 AM
> It appears that Linus's 2.6 git tree is missing some entryies in fsys.S.
> I don't know abot your particular GIT tree. In any case, here is a patch
> to fix this.

That's what the .space directive is for when I added it a couple of weeks
ago. It automatically fills in zero so lazy people like me can save a few
key strokes.  I guess the name __NR_syscall_last is not intuitive, it meant
to be last_non_zero entry for fsys table.

- Ken

See this posting:
http://www.gelato.unsw.edu.au/archives/linux-ia64/0602/16862.html

Re: missing entries in fsys.S

[Stephane Eranian]

Ken,

On Wed, Feb 15, 2006 at 08:15:44AM -0800, Chen, Kenneth W wrote:
> Stephane Eranian wrote on Wednesday, February 15, 2006 6:34 AM
> > It appears that Linus's 2.6 git tree is missing some entryies in fsys.S.
> > I don't know abot your particular GIT tree. In any case, here is a patch
> > to fix this.
> 
> That's what the .space directive is for when I added it a couple of weeks
> ago. It automatically fills in zero so lazy people like me can save a few
> key strokes.  I guess the name __NR_syscall_last is not intuitive, it meant
> to be last_non_zero entry for fsys table.
> 
Obviously, I missed that patch. I agree with you that it is tedious
to track new syscalls. Your trick is nice. I would certainly renamed
the syscall_last to NR_fsyscalls_lat or something like this.

Thanks.


-- 

-Stephane

RE: missing entries in fsys.S

[Chen, Kenneth W]

Stephane Eranian wrote on Wednesday, February 15, 2006 8:28 AM
> I would certainly renamed
> the syscall_last to NR_fsyscalls_lat or something like this.

How does the following patch look?  Is it better?


[patch] beautify coding style for zeroing end of fsyscall_table entries.
        Remove misleading __NR_syscall_last and add more comments.

Signed-off-by: Ken Chen <kenneth.w.chen@intel.com>


--- linux-2.6.16-rc3/arch/ia64/kernel/fsys.S.orig	2006-02-15 11:39:52.221926956 -0800
+++ linux-2.6.16-rc3/arch/ia64/kernel/fsys.S	2006-02-15 12:05:28.789290945 -0800
@@ -878,8 +878,10 @@ fsyscall_table:
 	data8 0				// timer_delete
 	data8 0				// clock_settime
 	data8 fsys_clock_gettime	// clock_gettime
-	#define __NR_syscall_last	1255
 
-	.space 8*(NR_syscalls + 1024 - __NR_syscall_last), 0
+	// fill in zeros for the remaining entries
+	.zero:
+	.space fsyscall_table + 8*NR_syscalls - .zero, 0
 
-	.org fsyscall_table + 8*NR_syscalls	// guard against failures to increase NR_syscalls
+	// guard against failures to increase NR_syscalls
+	.org fsyscall_table + 8*NR_syscalls

RE: missing entries in fsys.S

[Luck, Tony]

+	// guard against failures to increase NR_syscalls
+	.org fsyscall_table + 8*NR_syscalls

Is this redundant ... with the .space directive I don't think
that this can ever trip ... can it?

-Tony

RE: missing entries in fsys.S

[Chen, Kenneth W]

Luck, Tony wrote on Wednesday, February 15, 2006 11:40 AM
> +	// guard against failures to increase NR_syscalls
> +	.org fsyscall_table + 8*NR_syscalls
> 
> Is this redundant ... with the .space directive I don't think
> that this can ever trip ... can it?

Sadly gnu assembler gives only warning if .space's count argument
is zero or negative.

I agree that this is redundant given that we already check the
size in sys_call_table (entry.S).  So this can be removed.  Tony,
do you want me to send you another patch or you can just massage it?

- Ken

RE: missing entries in fsys.S

[Luck, Tony]

> Sadly gnu assembler gives only warning if .space's count argument
> is zero or negative.
> 
> I agree that this is redundant given that we already check the
> size in sys_call_table (entry.S).  So this can be removed.  Tony,
> do you want me to send you another patch or you can just massage it?

I think that the .org thing only gives a warning too.

I'll massage the patch (gives me a chance to try out the "git squash"
code that I'm working on).

-Tony