Re: [PATCH V2 05/19] csky: System Call
From: Arnd Bergmann
Date: Wed Jul 04 2018 - 17:04:49 EST
On Wed, Jul 4, 2018 at 1:49 PM, Guo Ren <ren_guo@xxxxxxxxx> wrote:
>> > +#define __NR_set_thread_area (__NR_arch_specific_syscall + 0)
>> > +__SYSCALL(__NR_set_thread_area, sys_set_thread_area)
>> > +#define __NR_ipc (__NR_arch_specific_syscall + 1)
>> > +__SYSCALL(__NR_ipc, sys_ipc)
>> > +#define __NR_socketcall (__NR_arch_specific_syscall + 2)
>> > +__SYSCALL(__NR_socketcall, sys_socketcall)
>> > +#define __NR_ugetrlimit (__NR_arch_specific_syscall + 3)
>> > +__SYSCALL(__NR_ugetrlimit, sys_getrlimit)
>> > +#define __NR_cacheflush (__NR_arch_specific_syscall + 4)
>> > +__SYSCALL(__NR_cacheflush, sys_cacheflush)
>> > +#define __NR_sysfs (__NR_arch_specific_syscall + 5)
>> > +__SYSCALL(__NR_sysfs, sys_sysfs)
>> > +
>> > +__SYSCALL(__NR_fadvise64_64, sys_csky_fadvise64_64)
>> We definitely don't want ipc, socketcall, ugetrlimit, or sysfs.
> Ok, remove them.
>> For fadvise64_64, please redefine the symbol name so the
>> table points at the right entry.
> We need exchange the args for abiv1. loff_t is 64bit and abiv1 need
> 8-bytes align in args.
> * for abiv1 the 64bits args should be even th, So we need mov the advice forward.
> int, fd,
> int, advice,
> loff_t, offset,
> loff_t, len)
> return sys_fadvise64_64(fd, offset, len, advice);
Right, I do understand what it's used for, my point was that you
don't really need a separate system call number for it, just redirect
the entry point using the same trick that nds32 has in
#define sys_fadvise64_64 csky_fadvise64_64
>> I'm not completely sure about set_thread_area, can you explain
>> what you need that for?
> In abiv1 there is no tls register, so we use "trap 3" for csky_get_tls
> defined in arch/csky/kernel/entry.S to get tls.
> Also we use set_thread_area to set tls in kernel.
> For abiv2 it has r31 for tls-reg, but we still keep the mechanism.