Blackfin arch: add some missing syscall

PATCH In review Bryan Wu 5 participants 12 messages Sep 13, 2007 – Sep 15, 2007 Generic include/asm header files

Share & tools

Bryan Wu

author

2007-09-13 08:00 UTC #0 lore raw

PATCH 1/1 Blackfin arch: add some missing syscall

When compiling the Blackfin kernel, checksyscalls.pl will report lots of missing syscalls warnings. This patch will add some missing syscalls which make sense on Blackfin arch.

Also add ignored syscall list to kill remaining warnings.

After appling this patch, toolchain should be rebuilt. Then recompiling the kernel with the new toolchain.

Signed-off-by Mike Frysinger <[email protected]>

Signed-off-by Bryan Wu <[email protected]>

---
 arch/blackfin/mach-common/entry.S |   18 ++++++++++--
 include/asm-blackfin/unistd.h     |   54 ++++++++++++++++++++++++++++++++++---
 2 files changed, 65 insertions(+), 7 deletions(-)

arch/blackfin/mach-common/entry.S +15 -3

index d61bba9..ef60f2e 100644
@@ -815,7 +815,7 @@ _extable:
 
 ALIGN
 ENTRY(_sys_call_table)
-	.long _sys_ni_syscall	/* 0  -  old "setup()" system call*/
+	.long _sys_restart_syscall	/* 0 */
 	.long _sys_exit
 	.long _sys_fork
 	.long _sys_read

@@ -984,7 +984,7 @@ ENTRY(_sys_call_table)
 	.long _sys_ni_syscall	/* for vm86 */
 	.long _sys_ni_syscall	/* old "query_module" */
 	.long _sys_ni_syscall	/* sys_poll */
-	.long _sys_ni_syscall	/* sys_nfsservctl */
+	.long _sys_nfsservctl
 	.long _sys_setresgid	/* setresgid16 */	/* 170 */
 	.long _sys_getresgid	/* getresgid16 */
 	.long _sys_prctl

@@ -1040,7 +1040,7 @@ ENTRY(_sys_call_table)
 	.long _sys_ni_syscall	/* reserved for TUX */
 	.long _sys_ni_syscall
 	.long _sys_gettid
-	.long _sys_ni_syscall	/* 225 */ /* sys_readahead */
+	.long _sys_readahead	/* 225 */
 	.long _sys_setxattr
 	.long _sys_lsetxattr
 	.long _sys_fsetxattr

@@ -1157,6 +1157,18 @@ ENTRY(_sys_call_table)
 	.long _sys_shmctl
 	.long _sys_shmdt	/* 340 */
 	.long _sys_shmget
+	.long _sys_splice
+	.long _sys_sync_file_range
+	.long _sys_tee
+	.long _sys_vmsplice	/* 345 */
+	.long _sys_epoll_pwait
+	.long _sys_utimensat
+	.long _sys_signalfd
+	.long _sys_timerfd
+	.long _sys_eventfd	/* 350 */
+	.long _sys_pread64
+	.long _sys_pwrite64
+	.long _sys_fadvise64
 	.rept NR_syscalls-(.-_sys_call_table)/4
 	.long _sys_ni_syscall
 	.endr

include/asm-blackfin/unistd.h +50 -4

86 lines not on this page · raw message

Signature · 1 line

1.5.2

Paul Mundt

2007-09-13 08:07 UTC #1 lore raw

Quoted 12 lines · Bryan Wu

include/asm-blackfin/unistd.h +7 -1

@@ -352,9 +353,54 @@
 #define __NR_shmdt		340
 #define __NR_shmget		341
 
-#define __NR_syscall		342
+#define __NR_splice		342
+#define __NR_sync_file_range	343
+#define __NR_tee		344
+#define __NR_vmsplice		345
+
+#define __NR_epoll_pwait	346
+#define __NR_utimensat		347

include/asm-blackfin/unistd.h line 372

Quoted 10 lines

include/asm-blackfin/unistd.h +8 -0

+#define __NR_signalfd		348
+#define __NR_timerfd		349
+#define __NR_eventfd		350
+#define __NR_pread64		351
+#define __NR_pwrite64		352
+#define __NR_fadvise64		353
+
+#define __NR_syscall		354
 #define NR_syscalls		__NR_syscall

Err, why did you change __NR_syscall? This is going to break the ABI for anything using it, which is generally bad form.

You also missed sys_fallocate(), another reason to be using git, rather than some silly subversion tree ;-)

Paul Mundt

2007-09-13 08:10 UTC #2 lore raw

Quoted 7 lines · Paul Mundt

Quoted 3 lines · Bryan Wu
+#define __NR_syscall 354
#define NR_syscalls __NR_syscall
Err, why did you change __NR_syscall? This is going to break the ABI for anything using it, which is generally bad form.

I can't read or think today, nevermind. The sys_fallocate() thing still stands, though.

Matthew Wilcox

2007-09-13 08:18 UTC #3 lore raw

In reply to Bryan Wu

Quoted 1 line · Bryan Wu

+/* Not relevant on no-mmu */

I thought this list seemed a little long, so I investigated a couple of them. mbind makes sense (it's only implemented for NUMA ... a NUMA embedded platform? not the kind which runs applications that use mbind), but mremap doesn't -- there's even an implementation in mm/nommu.c. Could you check the rest of these over to see if they truly don't need to be implemented for no-mmu? I think you'll want the *robust_list syscalls too.

Quoted 19 lines

include/asm-blackfin/unistd.h +19 -0

+#define __IGNORE_swapon
+#define __IGNORE_swapoff
+#define __IGNORE_msync
+#define __IGNORE_mlock
+#define __IGNORE_munlock
+#define __IGNORE_mlockall
+#define __IGNORE_munlockall
+#define __IGNORE_mremap
+#define __IGNORE_mincore
+#define __IGNORE_madvise
+#define __IGNORE_remap_file_pages
+#define __IGNORE_mbind
+#define __IGNORE_get_mempolicy
+#define __IGNORE_set_mempolicy
+#define __IGNORE_migrate_pages
+#define __IGNORE_set_robust_list
+#define __IGNORE_get_robust_list
+#define __IGNORE_move_pages
+#define __IGNORE_getcpu

Signature · 4 lines

Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Mike Frysinger

2007-09-13 08:37 UTC #4 lore raw

Quoted 6 lines · Matthew Wilcox

Quoted 1 line · Bryan Wu
+/* Not relevant on no-mmu */
I thought this list seemed a little long, so I investigated a couple of them. mbind makes sense (it's only implemented for NUMA ... a NUMA embedded platform? not the kind which runs applications that use mbind),

sorry, i dont quite follow ... you're saying it does or doesnt make sense to have NUMA syscalls on a no-mmu platform ? my [limited] understanding of NUMA is that it, by definition, requires a MMU in order to shunt pages around

Quoted 3 lines

but mremap doesn't -- there's even an implementation in mm/nommu.c. Could you check the rest of these over to see if they truly don't need to be implemented for no-mmu?

you're right we want mremap, my fault

Quoted 1 line

I think you'll want the *robust_list syscalls too.

lack of man pages on these made be lazy and dump em into the mmu pile when in reality they have nothing to do with it ... we do want these

Quoted 2 lines

include/asm-blackfin/unistd.h line 385
Quoted 2 lines
include/asm-blackfin/unistd.h +2 -0
+#define __IGNORE_swapon
+#define __IGNORE_swapoff

a no brainer -- not usable on no-mmu

Quoted 8 lines

include/asm-blackfin/unistd.h line 393

Quoted 8 lines

include/asm-blackfin/unistd.h +8 -0

+#define __IGNORE_msync
+#define __IGNORE_remap_file_pages
+#define __IGNORE_mlock
+#define __IGNORE_munlock
+#define __IGNORE_mlockall
+#define __IGNORE_munlockall
+#define __IGNORE_mincore
+#define __IGNORE_madvise

implementation only exists for mmu

Quoted 5 lines

include/asm-blackfin/unistd.h line 401
Quoted 5 lines
include/asm-blackfin/unistd.h +5 -0
+#define __IGNORE_mbind
+#define __IGNORE_get_mempolicy
+#define __IGNORE_set_mempolicy
+#define __IGNORE_migrate_pages
+#define __IGNORE_move_pages

NUMA only

Quoted 3 lines

include/asm-blackfin/unistd.h line 400
Quoted 3 lines
include/asm-blackfin/unistd.h +3 -0
+#define __IGNORE_mremap
+#define __IGNORE_set_robust_list
+#define __IGNORE_get_robust_list

we want these

Quoted 1 line

Quoted 1 line
+#define __IGNORE_getcpu

useful only with SMP so i guess we should do it
-mike

Bryan Wu

author

2007-09-13 09:01 UTC #5 lore raw

Quoted 4 lines · Mike Frysinger

Quoted 3 lines · Matthew Wilcox
Quoted 1 line · Bryan Wu
+/* Not relevant on no-mmu */

Quoted 9 lines

Quoted 3 lines
I thought this list seemed a little long, so I investigated a couple of them. mbind makes sense (it's only implemented for NUMA ... a NUMA embedded platform? not the kind which runs applications that use mbind),
sorry, i dont quite follow ... you're saying it does or doesnt make sense to have NUMA syscalls on a no-mmu platform ? my [limited] understanding of NUMA is that it, by definition, requires a MMU in order to shunt pages around

I think Matt means mbind can be ignored because it is for NUMA.

Quoted 6 lines

Quoted 3 lines
but mremap doesn't -- there's even an implementation in mm/nommu.c. Could you check the rest of these over to see if they truly don't need to be implemented for no-mmu?
you're right we want mremap, my fault

Yes, I do think so, both sys_mremap and sys_munmap are implemented in mm/nommu.c. How do think of this, Bernd?

Quoted 5 lines

Quoted 1 line
I think you'll want the *robust_list syscalls too.
lack of man pages on these made be lazy and dump em into the mmu pile when in reality they have nothing to do with it ... we do want these

No man pages for this fancy syscalls. I found some info here:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e9056f13bfcdd054a0c3d730e4e096748d8a363a
I am not sure for these. Need some investigation.

Quoted 30 lines

Quoted 2 lines
include/asm-blackfin/unistd.h line 385
Quoted 2 lines
include/asm-blackfin/unistd.h +2 -0
+#define __IGNORE_swapon
+#define __IGNORE_swapoff
a no brainer -- not usable on no-mmu
Quoted 8 lines
include/asm-blackfin/unistd.h line 393
Quoted 8 lines
include/asm-blackfin/unistd.h +8 -0
+#define __IGNORE_msync
+#define __IGNORE_remap_file_pages
+#define __IGNORE_mlock
+#define __IGNORE_munlock
+#define __IGNORE_mlockall
+#define __IGNORE_munlockall
+#define __IGNORE_mincore
+#define __IGNORE_madvise
implementation only exists for mmu
Quoted 5 lines
include/asm-blackfin/unistd.h line 401
Quoted 5 lines
include/asm-blackfin/unistd.h +5 -0
+#define __IGNORE_mbind
+#define __IGNORE_get_mempolicy
+#define __IGNORE_set_mempolicy
+#define __IGNORE_migrate_pages
+#define __IGNORE_move_pages
NUMA only
Quoted 3 lines
include/asm-blackfin/unistd.h line 400
Quoted 3 lines
include/asm-blackfin/unistd.h +3 -0
+#define __IGNORE_mremap
+#define __IGNORE_set_robust_list
+#define __IGNORE_get_robust_list
we want these

Quoted 3 lines

Quoted 1 line
Quoted 1 line
+#define __IGNORE_getcpu
useful only with SMP so i guess we should do it

also the brand new syscall fallocate should be added as Paul said:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=97ac73506c0ba93f30239bb57b4cfc5d73e68a62

Thanks a lot
-Bryan

Bernd Schmidt

2007-09-13 11:03 UTC #6 lore raw

Quoted 8 lines · Bryan Wu

Quoted 5 lines
Quoted 3 lines
but mremap doesn't -- there's even an implementation in mm/nommu.c. Could you check the rest of these over to see if they truly don't need to be implemented for no-mmu?
you're right we want mremap, my fault
Yes, I do think so, both sys_mremap and sys_munmap are implemented in mm/nommu.c. How do think of this, Bernd?

There's a mremap in nommu.c, but it doesn't do a lot that is useful. With some further mm changes in our tree, it's little more than a fancy way of saying munmap, and uClibc does not use it, so there's no compelling need to have it in userspace.

Bernd

Signature · 4 lines

This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Bryan Wu

author

2007-09-14 05:49 UTC #7 lore raw

Quoted 7 lines · Bernd Schmidt

Quoted 6 lines · Bryan Wu
Quoted 5 lines
Quoted 3 lines
but mremap doesn't -- there's even an implementation in mm/nommu.c. Could you check the rest of these over to see if they truly don't need to be implemented for no-mmu?
you're right we want mremap, my fault

Quoted 8 lines

Quoted 2 lines
Yes, I do think so, both sys_mremap and sys_munmap are implemented in mm/nommu.c. How do think of this, Bernd?
There's a mremap in nommu.c, but it doesn't do a lot that is useful. With some further mm changes in our tree, it's little more than a fancy way of saying munmap, and uClibc does not use it, so there's no compelling need to have it in userspace.

Make sense. So currently Blackfin uClinux use the mremap/munmap in uClibc?

Thanks
-Bryan

Mike Frysinger

2007-09-14 06:44 UTC #8 lore raw

Quoted 11 lines · Bryan Wu

Quoted 10 lines · Bernd Schmidt
Quoted 8 lines · Bryan Wu
Quoted 5 lines
Quoted 3 lines
but mremap doesn't -- there's even an implementation in mm/nommu.c. Could you check the rest of these over to see if they truly don't need to be implemented for no-mmu?
you're right we want mremap, my fault
Yes, I do think so, both sys_mremap and sys_munmap are implemented in mm/nommu.c. How do think of this, Bernd?

Quoted 7 lines

Quoted 4 lines
There's a mremap in nommu.c, but it doesn't do a lot that is useful. With some further mm changes in our tree, it's little more than a fancy way of saying munmap, and uClibc does not use it, so there's no compelling need to have it in userspace.
Make sense. So currently Blackfin uClinux use the mremap/munmap in uClibc?

most functions like this dont have any real libc component ... uClibc will define userspace symbols that merely make a syscall iff the __NR_ exists in the headers

if we have __NR_mremap in our unistd.h, we'll automagically get the mremap() symbol in uClibc which simply passes along the args to the kernel
-mike

Bryan Wu

author

2007-09-14 07:36 UTC #9 lore raw

Quoted 20 lines · Mike Frysinger

Quoted 11 lines · Bryan Wu
Quoted 10 lines · Bernd Schmidt
Quoted 8 lines · Bryan Wu
Quoted 5 lines
Quoted 3 lines
but mremap doesn't -- there's even an implementation in mm/nommu.c. Could you check the rest of these over to see if they truly don't need to be implemented for no-mmu?
you're right we want mremap, my fault
Yes, I do think so, both sys_mremap and sys_munmap are implemented in mm/nommu.c. How do think of this, Bernd?
Quoted 7 lines
Quoted 4 lines
There's a mremap in nommu.c, but it doesn't do a lot that is useful. With some further mm changes in our tree, it's little more than a fancy way of saying munmap, and uClibc does not use it, so there's no compelling need to have it in userspace.
Make sense. So currently Blackfin uClinux use the mremap/munmap in uClibc?

Quoted 7 lines

most functions like this dont have any real libc component ... uClibc will define userspace symbols that merely make a syscall iff the __NR_ exists in the headers
if we have __NR_mremap in our unistd.h, we'll automagically get the mremap() symbol in uClibc which simply passes along the args to the kernel

Yes, I know this. But currently, __NR_mremap does not exit in Blackfin unistd.h:
/* 163 __NR_mremap */.

So the implementation of this kind syscalls should be in uClibc, right?

And Bernd said that the kernel version mremap/munmap is not very useful for Blackfin arch. I think mremap/munmap can be ignored in Blackfin.

Thanks
-Bryan

Mike Frysinger

2007-09-15 01:28 UTC #10 lore raw

Quoted 29 lines · Bryan Wu

Quoted 20 lines · Mike Frysinger
Quoted 11 lines · Bryan Wu
Quoted 10 lines · Bernd Schmidt
Quoted 8 lines · Bryan Wu
Quoted 5 lines
Quoted 3 lines
but mremap doesn't -- there's even an implementation in mm/nommu.c. Could you check the rest of these over to see if they truly don't need to be implemented for no-mmu?
you're right we want mremap, my fault
Yes, I do think so, both sys_mremap and sys_munmap are implemented in mm/nommu.c. How do think of this, Bernd?
Quoted 7 lines
Quoted 4 lines
There's a mremap in nommu.c, but it doesn't do a lot that is useful. With some further mm changes in our tree, it's little more than a fancy way of saying munmap, and uClibc does not use it, so there's no compelling need to have it in userspace.
Make sense. So currently Blackfin uClinux use the mremap/munmap in uClibc?
Quoted 7 lines
most functions like this dont have any real libc component ... uClibc will define userspace symbols that merely make a syscall iff the __NR_ exists in the headers
if we have __NR_mremap in our unistd.h, we'll automagically get the mremap() symbol in uClibc which simply passes along the args to the kernel

Quoted 5 lines

Yes, I know this. But currently, __NR_mremap does not exit in Blackfin unistd.h:
/* 163 __NR_mremap */.
So the implementation of this kind syscalls should be in uClibc, right?

no ... if the kernel supports it, uClibc supports ... if the kernel doesnt support, uClibc doesnt support it

adding a ghetto userspace implementation to workaround this is weak ... that'll just mean random bugs may crop up on us that dont exist for any other architecture simply because we opted not to hook up the common kernel version

either we support it and have the kernel pull in the common one or we dont support ... no middle ground here
-mike

Paul Mundt

2007-09-13 08:47 UTC #11 lore raw

In reply to Matthew Wilcox

Quoted 6 lines · Matthew Wilcox

Quoted 1 line · Bryan Wu
+/* Not relevant on no-mmu */
I thought this list seemed a little long, so I investigated a couple of them. mbind makes sense (it's only implemented for NUMA ... a NUMA embedded platform? not the kind which runs applications that use mbind),

There are embedded platforms that are using NUMA memory policies, including mbind() in applications for setting them. Page migration is a little iffier, but that can be turned off. Embedded platforms with multiple memories (and a different cost per memory) are quite common, and they're getting large enough to offset the overhead of a pgdat + bootmem map. We have them on nommu also, but that's not been hacked up generically yet.