From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1A67C282DD for ; Wed, 8 Jan 2020 18:11:42 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7BC7B20656 for ; Wed, 8 Jan 2020 18:11:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7BC7B20656 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:47698 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ipFnw-0005jE-Js for qemu-devel@archiver.kernel.org; Wed, 08 Jan 2020 13:11:40 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34730) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ipFnG-00052c-PZ for qemu-devel@nongnu.org; Wed, 08 Jan 2020 13:10:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ipFnF-0006Xf-IM for qemu-devel@nongnu.org; Wed, 08 Jan 2020 13:10:58 -0500 Received: from indium.canonical.com ([91.189.90.7]:33094) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ipFnF-0006Vr-Cw for qemu-devel@nongnu.org; Wed, 08 Jan 2020 13:10:57 -0500 Received: from loganberry.canonical.com ([91.189.90.37]) by indium.canonical.com with esmtp (Exim 4.86_2 #2 (Debian)) id 1ipFnC-0003eo-P0 for ; Wed, 08 Jan 2020 18:10:54 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id BA76F2E80C9 for ; Wed, 8 Jan 2020 18:10:54 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Wed, 08 Jan 2020 17:56:17 -0000 From: Peter Maydell To: qemu-devel@nongnu.org X-Launchpad-Notification-Type: bug X-Launchpad-Bug: product=qemu; status=New; importance=Undecided; assignee=None; X-Launchpad-Bug-Information-Type: Public X-Launchpad-Bug-Private: no X-Launchpad-Bug-Security-Vulnerability: no X-Launchpad-Bug-Commenters: aladjev-andrew amarkovic pmaydell X-Launchpad-Bug-Reporter: puchuu (aladjev-andrew) X-Launchpad-Bug-Modifier: Peter Maydell (pmaydell) References: <157833123209.15024.12557979334447840996.malonedeb@wampee.canonical.com> <157850256701.5510.8747112724719044821.malone@gac.canonical.com> Message-Id: Subject: Re: [Bug 1858461] Re: Please refactor linux-user/mips/cpu_loop.c X-Launchpad-Message-Rationale: Subscriber (QEMU) @qemu-devel-ml X-Launchpad-Message-For: qemu-devel-ml Precedence: bulk X-Generated-By: Launchpad (canonical.com); Revision="bceb5ef013b87ef7aafe0755545ceb689ca7ac60"; Instance="production-secrets-lazr.conf" X-Launchpad-Hash: 502d22fab78ddabc98069791dccbf2eb224c4294 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 91.189.90.7 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Bug 1858461 <1858461@bugs.launchpad.net> Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Message-ID: <20200108175617.spU9p8KZz0NGDl6DOKT9lvhP6RAN4J7M9MrbozYMpjk@z> On Wed, 8 Jan 2020 at 17:06, puchuu <1858461@bugs.launchpad.net> wrote: > I think about the following development flow: > > 1. Kernel updates and maintains "tbl". > 2. Qemu developer wants to implement new syscall (like clone3) in "linux-= user/syscall.c". > 3. Developer clones new kernel into some directory and runs generators. > 4. All syscall related stuff will be updated immediately. That seems like quite a lot of effort, given that we don't really have to update the set of syscall number #defines very often. At the moment it's just "somebody submits a patch which updates the list of #defines every so often". (And if you want to actually implement a new syscall then the the actual implementation is the bulk of the work anyhow.) In particular if you really want to proceed down the path of suggesting scripts for doing the update then I think we would want something that works for all our architectures, not just MIPS. thanks -- PMM -- = You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1858461 Title: Please refactor linux-user/mips/cpu_loop.c Status in QEMU: New Bug description: Hello. I am working with qemu on test images. I've added a new syscall (436) to qemu but received ENOSYS from mips application. Please open "linux-user/mips/cpu_loop.c". I've added at the end of "mips_syscall_args" the following: ``` MIPS_SYS(sys_getdents64_x32, 3) ``` But ``` syscall_num =3D env->active_tc.gpr[2] - 4000; if (syscall_num >=3D sizeof(mips_syscall_args)) { ret =3D -TARGET_ENOSYS; ``` returns -TARGET_ENOSYS We can see that "linux-user/mips/cpu_loop.c" differs a lot from "linux-user/arm/cpu_loop.c". Arm has it's own "ARM_NR_BASE" and etc. Can you please refactor mips cpu loop in the same way as arm? Thank you. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1858461/+subscriptions