Received: by 10.223.164.202 with SMTP id h10csp2792672wrb; Sun, 12 Nov 2017 18:52:23 -0800 (PST) X-Google-Smtp-Source: AGs4zMZ2GjBIGeGuEwPbw7Jwy4zoU4uOJSZWp/lvGYfzgGBS2vVrdwFjtexZ+DXh5Jh3V7pKTVpM X-Received: by 10.101.92.202 with SMTP id b10mr7422774pgt.164.1510541543500; Sun, 12 Nov 2017 18:52:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510541543; cv=none; d=google.com; s=arc-20160816; b=E31r8mG3CJ4cAbya29DXyqVTgjIkWrb7ljfQGCVbZUyv64mCM416azJjxsq1DIh79g kADEc636HIyYfD02bY105e+GSRcT4FXGrOlvtZdBYQTeeLr7HmvQb49pCC6QbC8LCWLc cbywxW24BU9cDLFwjesKqlzUCQER2Xd6u8LvMu1PBPgN4muagtfUQQl669X1RovCkTjn xDOxYzQeMXtC6qqZdLh9odyD411pm30vVNCzCWDtAuFwkXJqTVfZLKbvk+C3R7iKCqll xMxJge+wSMDoq/kW5JbBs4vhxFPWEjzigYNmubgzqF/ZiBwNiG9t17hWLFWZ54O8c9hz wIKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=jEOWwNmSOG+ng4tUnRGEWhDAGqOLpiO/qHF9wi7maO8=; b=sC62QrlbO5ZLsCuB/I0ImtbdMHLiQ98j0fQpEQ7/a4lV7cWv96kWoP5yIFRKpqS4x/ y/mmMq8U2uVnGV+SkEJeYpr4PIiA/kwxGokTgwD0XT7cKlQWezJRKetGX0A00MvLRLb3 B9yjmrMCIZv05llXYf+bML/r3t5eoq4AnoKh19huovgRgbvjQVryI6j7w/PjSYA1ggHn s7eS5yVVM4UXMhyV++yG/LPEm14/kpxW6FQEeqKcODPcVm5LGnyOdZQ1PLmbYvT5fRyk cO6n1LdU698nwfZ5xZOedWdasTVY6holkIbS5Twe1EnvxaHjhRNRjz3jD1loaC6ARHci z0Sw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=VDun2wMX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p3si2960454pld.437.2017.11.12.18.51.59; Sun, 12 Nov 2017 18:52:23 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=VDun2wMX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751432AbdKMCvD (ORCPT + 87 others); Sun, 12 Nov 2017 21:51:03 -0500 Received: from mail-io0-f193.google.com ([209.85.223.193]:55972 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751065AbdKMCvB (ORCPT ); Sun, 12 Nov 2017 21:51:01 -0500 Received: by mail-io0-f193.google.com with SMTP id p186so19056052ioe.12; Sun, 12 Nov 2017 18:51:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jEOWwNmSOG+ng4tUnRGEWhDAGqOLpiO/qHF9wi7maO8=; b=VDun2wMXBSFNdtjGmGaqGG5sKTBVCitjGvQmqV7FUzDCbKDAiaIgZiVh4a86NI5vs6 TJVvsXMBwdvdUiOnXEAPR6CYQWLL6K+VwNmNz44n7RXOGROmBy9NDSwc0EtJzJ4VlXtj Ykp9+lAc14MbyhLJ31EplLjebktg3bqoHTzf1JdHDWLNIVgEqsMm1+EnVYpHm2SLcZZt XKmyyxkzqYP6SNPNeumdS7hsQodKVVKEupC/N5XiIW9inc2CoZZiTDXrCWXAZPvCo1bO wM+G4Uuz4lxdbEGSGcPdn4vSwha0lwxJmvbJaCFuv9PiBvMK8Vv5LEvkAEeXr4JxhvET eFig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jEOWwNmSOG+ng4tUnRGEWhDAGqOLpiO/qHF9wi7maO8=; b=jiGNRZfazx4Eyci6piG2RTeG0zrlsR0GQVHzTt40trToYYZCqITpq+lm88xQDZWl9J 0SHXbWGDHOdcGOP7GFJQAeCbIA4QR4cj/D9auOA9breMfIB8IRmuyyaRh4mDJVtuIhIV ryX4s/IKxbamM/xcBNcgfbAeJK0vEAX1LDXJfHQAaGB4Q8AX6LHUNWQd623xJkYlvIoH PVYPfrkzinVmVv1lk9a1mDC5vlwAp45yXQ83htsQPFIE9WgSmpDz+Enw64Qd4ZHsKjqo mRPOFz/ezd8wh52qZFrRonaH82kiR08oJObVu2KHL6uscZWIQ+dMb/gJ0HbBSxXiDK21 vT3Q== X-Gm-Message-State: AJaThX7aYQZfjiEV4yLxOFEZ7JeEHhYYQdBWtutqjcMa59chrwNTXCGW Iomd5yKe+pqWBUP2FEyGFFOkS/BROcW1l/JOo0T8Wg== X-Received: by 10.107.68.8 with SMTP id r8mr8645638ioa.192.1510541460737; Sun, 12 Nov 2017 18:51:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.62.213 with HTTP; Sun, 12 Nov 2017 18:51:00 -0800 (PST) In-Reply-To: References: <61b5cd5e7f2cf2f485a990cdf238788b817a1d53.1510118606.git.green.hu@gmail.com> From: Vincent Chen Date: Mon, 13 Nov 2017 10:51:00 +0800 Message-ID: Subject: Fwd: FW: [PATCH 15/31] nds32: System calls handling To: Arnd Bergmann Cc: greentime@andestech.com, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, tglx@linutronix.de, jason@lakedaemon.net, marc.zyngier@arm.com, robh+dt@kernel.org, netdev@vger.kernel.org, vincentc@andestech.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>On Wed, Nov 8, 2017 at 6:55 AM, Greentime Hu wrote: >> From: Greentime Hu > >> +#endif /* __ASM_NDS32_SYSCALLS_H */ >> diff --git a/arch/nds32/include/asm/unistd.h >> b/arch/nds32/include/asm/unistd.h new file mode 100644 index >> 0000000..b30adca >> --- /dev/null >> +++ b/arch/nds32/include/asm/unistd.h >> @@ -0,0 +1,21 @@ > >> +#define __ARCH_WANT_SYS_LLSEEK > >This gets set from include/asm-generic/unistd.h if you include that file. > Dear Arnd: Thanks I will remove it in the next version patch. >> +#define __ARCH_WANT_SYS_CLONE > >This seems ok, though it would be nice to have the reverse logic and have architectures opt-out of the generic version when they need to provide their own, rather than having most architectures set it. > Thanks I will provide nds32 SYSCALL_DEFINE_5(clone) in the next version patch. >> +#define __ARCH_WANT_SYS_OLD_MMAP > >I don't see why you need this, can it be dropped? Thanks I will remove it in the next version patch. > >> diff --git a/arch/nds32/include/uapi/asm/unistd.h >> b/arch/nds32/include/uapi/asm/unistd.h >> new file mode 100644 >> index 0000000..01b466d >> --- /dev/null >> +++ b/arch/nds32/include/uapi/asm/unistd.h > >> +#define __NR_ipc (__NR_arch_specific_syscall + 2) >> +#define __NR_sysfs (__NR_arch_specific_syscall + 3) >> +#define __NR__llseek __NR_llseek > > > >> +__SYSCALL(__NR_cacheflush, sys_cacheflush) __SYSCALL(__NR_syscall, >> +sys_syscall) __SYSCALL(__NR_ipc, sys_ipc) __SYSCALL(__NR_sysfs, >> +sys_sysfs) >> + >> +__SYSCALL(__NR_fadvise64_64, sys_fadvise64_64_wrapper) >> +__SYSCALL(__NR_rt_sigreturn, sys_rt_sigreturn_wrapper) >> +__SYSCALL(__NR_mmap, sys_old_mmap) > >Usually we handle those overrides by defining the macros in asm/unistd.h before including the asm-generic version. Can you do that as well for consistency? > Thanks Ok, I will modify it in the next version patch >I don't see a reason for sys_ipc, sys_sysfs or sys_old_mmap() here in a new architecture. Can you drop those or explain why you need them? > Thanks I will remove them in the next version patch >> +/* >> + * Special system call wrappers >> + * >> + * $r0 = syscall number >> + * $r8 = syscall table >> + */ >> + .type sys_syscall, #function >> +ENTRY(sys_syscall) >> + addi $p1, $r0, #-__NR_syscalls >> + bgtz $p1, 3f >> + move $p1, $r0 >> + move $r0, $r1 >> + move $r1, $r2 >> + move $r2, $r3 >> + move $r3, $r4 >> + move $r4, $r5 >> +! add for syscall 6 args >> + lwi $r5, [$sp + #SP_OFFSET ] >> + lwi $r5, [$r5] >> +! ~add for syscall 6 args >> + >> + lw $p1, [tbl+$p1<<2] >> .+ jr $p1 >> +3: b sys_ni_syscall >> +ENDPROC(sys_syscall) > >Can you explain what this is used for? > This is used to handle syscall(int number, ....). Unlike other architectures, the system number shall be determined in compile time when issuing system call in nds32. Therefore, we only can parse the content of syscall(int number, ....) and distribute it to destination handler in kernel space (Other architecture can handle it in user space by glibc's syscall wrapper) >> --- /dev/null >> +++ b/arch/nds32/kernel/sys_nds32.c >> + >> +long sys_mmap2(unsigned long addr, unsigned long len, >> + unsigned long prot, unsigned long flags, >> + unsigned long fd, unsigned long pgoff) { >> + if (pgoff & (~PAGE_MASK >> 12)) >> + return -EINVAL; >> + >> + return sys_mmap_pgoff(addr, len, prot, flags, fd, >> + pgoff >> (PAGE_SHIFT - 12)); } >> + >> +asmlinkage long sys_fadvise64_64_wrapper(int fd, int advice, loff_t offset, >> + loff_t len) { >> + return sys_fadvise64_64(fd, offset, len, advice); } > >You should always use SYSCALL_DEFINE*() macros to define entry points for your own syscalls in C code for consistency. I also wonder if we should just move those two into common code, a lot of architectures need the first one in particular. > The sys_fadvise64_64_wrapper is used to reorder the input parameter. In order to solve register alignment problem, we adjust the input parameter order of fadvise64_64 while issuing this syscall. Therefore, we need this wrapper to reorder the input parameter to fit sys_fadvise64_64's API in kernel. > Arnd Best regard Vincent From 1583489838732183286@xxx Wed Nov 08 09:33:09 +0000 2017 X-GM-THRID: 1583483337964688427 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread