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(-)
diff --git a/arch/blackfin/mach-common/entry.S b/arch/blackfin/mach-common/entry.S
index d61bba9..ef60f2e 100644
--- a/arch/blackfin/mach-common/entry.S
+++ b/arch/blackfin/mach-common/entry.S
@@ -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
diff --git a/include/asm-blackfin/unistd.h b/include/asm-blackfin/unistd.h
index 0df9f2d..2de4cd2 100644
--- a/include/asm-blackfin/unistd.h
+++ b/include/asm-blackfin/unistd.h
@@ -3,6 +3,7 @@
/*
* This file contains the system call numbers.
*/
+#define __NR_restart_syscall 0
#define __NR_exit 1
#define __NR_fork 2
#define __NR_read 3
@@ -171,7 +172,7 @@
/* 166 __NR_vm86 */
/* 167 __NR_query_module */
/* 168 __NR_poll */
- /* 169 __NR_nfsservctl */
+#define __NR_nfsservctl 169
#define __NR_setresgid 170
#define __NR_getresgid 171
#define __NR_prctl 172
@@ -227,7 +228,7 @@
/* 222 reserved for TUX */
/* 223 reserved for TUX */
#define __NR_gettid 224
- /* 225 __NR_readahead */
+#define __NR_readahead 225
#define __NR_setxattr 226
#define __NR_lsetxattr 227
#define __NR_fsetxattr 228
@@ -287,7 +288,7 @@
#define __NR_mq_timedreceive (__NR_mq_open+3)
#define __NR_mq_notify (__NR_mq_open+4)
#define __NR_mq_getsetattr (__NR_mq_open+5)
- /* 284 __NR_sys_kexec_load */
+#define __NR_kexec_load 284
#define __NR_waitid 285
#define __NR_add_key 286
#define __NR_request_key 287
@@ -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
+#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
+/* Old optional stuff no one actually uses */
+#define __IGNORE_sysfs
+#define __IGNORE_uselib
+
+/* Implement the newer interfaces */
+#define __IGNORE_mmap
+#define __IGNORE_poll
+#define __IGNORE_select
+#define __IGNORE_utime
+
+/* Not relevant on no-mmu */
+#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
+
#ifdef __KERNEL__
#define __ARCH_WANT_IPC_PARSE_VERSION
#define __ARCH_WANT_STAT64
--
1.5.2
On Thu, Sep 13, 2007 at 03:56:43PM +0800, Bryan Wu wrote:
> @@ -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
> +#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 ;-)
On Thu, Sep 13, 2007 at 05:07:01PM +0900, Paul Mundt wrote:
> On Thu, Sep 13, 2007 at 03:56:43PM +0800, Bryan Wu wrote:
> > +#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.
On Thu, Sep 13, 2007 at 03:56:43PM +0800, Bryan Wu wrote:
> +/* 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.
> +#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
--
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."
On 9/13/07, Matthew Wilcox <[email protected]> wrote:
> On Thu, Sep 13, 2007 at 03:56:43PM +0800, Bryan Wu wrote:
> > +/* 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
> 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
> 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
> > +#define __IGNORE_swapon
> > +#define __IGNORE_swapoff
a no brainer -- not usable on no-mmu
> > +#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
> > +#define __IGNORE_mbind
> > +#define __IGNORE_get_mempolicy
> > +#define __IGNORE_set_mempolicy
> > +#define __IGNORE_migrate_pages
> > +#define __IGNORE_move_pages
NUMA only
> > +#define __IGNORE_mremap
> > +#define __IGNORE_set_robust_list
> > +#define __IGNORE_get_robust_list
we want these
> > +#define __IGNORE_getcpu
useful only with SMP so i guess we should do it
-mike
On Thu, Sep 13, 2007 at 02:18:52AM -0600, Matthew Wilcox wrote:
> On Thu, Sep 13, 2007 at 03:56:43PM +0800, Bryan Wu wrote:
> > +/* 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.
On Thu, 2007-09-13 at 04:37 -0400, Mike Frysinger wrote:
> On 9/13/07, Matthew Wilcox <[email protected]> wrote:
> > On Thu, Sep 13, 2007 at 03:56:43PM +0800, Bryan Wu wrote:
> > > +/* 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
>
I think Matt means mbind can be ignored because it is for NUMA.
> > 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?
> > 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.
> > > +#define __IGNORE_swapon
> > > +#define __IGNORE_swapoff
>
> a no brainer -- not usable on no-mmu
>
> > > +#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
>
> > > +#define __IGNORE_mbind
> > > +#define __IGNORE_get_mempolicy
> > > +#define __IGNORE_set_mempolicy
> > > +#define __IGNORE_migrate_pages
> > > +#define __IGNORE_move_pages
>
> NUMA only
>
> > > +#define __IGNORE_mremap
> > > +#define __IGNORE_set_robust_list
> > > +#define __IGNORE_get_robust_list
>
> we want these
>
> > > +#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
Bryan Wu wrote:
>>> 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
--
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
On Thu, 2007-09-13 at 13:03 +0200, Bernd Schmidt wrote:
> Bryan Wu wrote:
> >>> 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.
>
Make sense. So currently Blackfin uClinux use the mremap/munmap in
uClibc?
Thanks
-Bryan
On 9/14/07, Bryan Wu <[email protected]> wrote:
> On Thu, 2007-09-13 at 13:03 +0200, Bernd Schmidt wrote:
> > Bryan Wu wrote:
> > >>> 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.
>
> 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
On Fri, 2007-09-14 at 02:44 -0400, Mike Frysinger wrote:
> On 9/14/07, Bryan Wu <[email protected]> wrote:
> > On Thu, 2007-09-13 at 13:03 +0200, Bernd Schmidt wrote:
> > > Bryan Wu wrote:
> > > >>> 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.
> >
> > 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
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
On 9/14/07, Bryan Wu <[email protected]> wrote:
> On Fri, 2007-09-14 at 02:44 -0400, Mike Frysinger wrote:
> > On 9/14/07, Bryan Wu <[email protected]> wrote:
> > > On Thu, 2007-09-13 at 13:03 +0200, Bernd Schmidt wrote:
> > > > Bryan Wu wrote:
> > > > >>> 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.
> > >
> > > 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
>
> 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