Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp5215895rwd; Sun, 4 Jun 2023 23:31:50 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4h+3A+LTcFHOSBzvY6BsMQElfCHFhCxwWtGEgf6aTqMQn9J7S/N/pLQTH0KOwnVi2gqEtt X-Received: by 2002:a05:6870:d246:b0:19a:2343:b69e with SMTP id h6-20020a056870d24600b0019a2343b69emr7160570oac.40.1685946710597; Sun, 04 Jun 2023 23:31:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685946710; cv=none; d=google.com; s=arc-20160816; b=lYOvTwf0LShFM9F6VfWPC7Vbn4Hs834FyKemy71gYUKb+tH74wk2jHWqYp5nKbQFAj KxkNn074IlcwYU6JfQqB2zQ+yP49r7uA4Z/lB8RLcqt69JOLbT43Ec1TdigL2OaKuDH0 dvDTXKpHOjgBT9gZvac/D0JEh1HUvch9DyU0Cd4DHBkNBnRNNs2Htdz5q3eGi3DbyxuT 9YYyhyTyyePcctC+BMrmC3f/T1rkNMIYemJHtS0wH4B4a5IXIaSSnWLJw7m4p+6AUU1A W/569CAgI7nhtEUYHk37VlE81a22fPM27/YjQo9hWKpajL6sofPCUiIG4EDJmVnAYTjO Pcfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=GiPQPII5HkbmHHH0S1VR7wGfT1MMFHLKJlNVCO24GAY=; b=BXdNeW2VT1Si6FdKZf9OwYbpwJCFUaFfenQkj/VQWg6wHqlSbKgbY3eQq0lCZZXS8D 8RBewn/9F1m0O0hvUHt0VyRVvh+Tz+bOgRLyN+58XjJYwbT4det+Chh2GKFSiJf7PpUf +7y08zEvFbmN9TvPffa5uRHSxw/ZsFmj6wCZ5jdViDecBrupSbNd5+HvsVLj/l+cxXyt KUsn2h3FlJVrFIzAgnw/2NdbCh/SuSRzhB1TYf+HUeZm+MLidZRS04UEJ29/etxoj1jT +Tg36Yg5cYxdgs20LrF6YOEzbMShx5W2GDEyrfrMxMnw3zeW0PWZENDzV8aoul2PbMWo wG/g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s8-20020a632c08000000b005343c3db9ebsi4968782pgs.616.2023.06.04.23.31.36; Sun, 04 Jun 2023 23:31:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229683AbjFEGUU (ORCPT + 99 others); Mon, 5 Jun 2023 02:20:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44718 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229613AbjFEGUS (ORCPT ); Mon, 5 Jun 2023 02:20:18 -0400 Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 73A6BE9; Sun, 4 Jun 2023 23:20:13 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.17.1/8.17.1/Submit) id 3556Jors005856; Mon, 5 Jun 2023 08:19:50 +0200 Date: Mon, 5 Jun 2023 08:19:50 +0200 From: Willy Tarreau To: Zhangjin Wu Cc: thomas@t-8ch.de, arnd@arndb.de, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-riscv@lists.infradead.org Subject: Re: [PATCH 1/4] tools/nolibc: unistd.h: add __syscall() and __syscall_ret() helpers Message-ID: References: <20230605055857.135286-1-falcon@tinylab.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230605055857.135286-1-falcon@tinylab.org> X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FORGED_SPF_HELO, SPF_HELO_PASS,T_SCC_BODY_TEXT_LINE,T_SPF_TEMPERROR autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 05, 2023 at 01:58:57PM +0800, Zhangjin Wu wrote: > > What about something like this: > > > > static inline long __ret_as_errno(long ret) /* or some other name */ > > { > > if (ret < 0) { > > SET_ERRNO(-ret); > > ret = -1; > > } > > return ret; > > } > > > > This avoids another macro by using a normal function. > > > > It is reasonable, like it very much. > > > Syscall return values should always fit into long, at least > > extra polating from syscall(2) and the fact that they are returned in > > registers. > > Yes, I did use 'long' instead of 'int' for unistd.h locally, but since tried to > let it work with 'void *' before (e.g. sys_brk, an older version support pass > the errno value), so, the typeof() is used and the same to unistd.h, but at > last, none of (void *) return type is really used in current patchset, so, we > are able to use this normal function version without the checking of the type. > > > > > It would be a bit more verbose: > > > > int chdir(const char *path) > > { > > return __ret_as_errno(sys_chdir(path)); > > } > > > > But it's clear what's going on and also just one line. > > Thanks Thomas, It looks good and I do like the 'embedded' calling of > sys_chrdir(path), but __syscall() looks cleaner and shorter too, let's put them > together: > > int chdir(const char *path) > { > return __ret_as_errno(sys_chdir(path)); > } > > int chdir(const char *path) > { > return __syscall(chdir, path); > } > > And even with: > > int chdir(const char *path) > { > return __sysret(sys_chdir(path)); > } > > __syscall() works likes syscall(), and the definition is similar to syscall(), > but uses the syscall name instead of syscall number, If reserve __syscall(), > the inline function would be renamed back to __syscall_ret() or something like > the shorter __sysret(), to align with our new __syscall(). > > for sys.h: > > /* Syscall return helper, set errno as ret when ret < 0 */ > static inline long __sysret(long ret) > { > if (ret < 0) { > SET_ERRNO(-ret); > ret = -1; > } > return ret; > } > > /* Syscall call helper, use syscall name instead of syscall number */ > #define __syscall(name, ...) __sysret(sys_##name(__VA_ARGS__)) > > for unistd.h: > > #define _syscall(N, ...) __sysret(my_syscall##N(__VA_ARGS__)) > > What about this version? > > The potential 'issue' may be mixing the use of __syscall(), _syscall() and > syscall(), but the compilers may help to fix up this for us, I don't think it > is a bottleneck. I think that could work. However, please place __attribute__((always_inline)) on these inline functions, as we don't want to turn them to function calls even at -O0. I'm traveling today, I'll let you and Thomas debate and decide how you'd like this to evolve. Also, please note that Paul is OK with merging for 6.5, but we should absolutely limit last-minute changes to the strict minimum we're able to test now. Thanks! Willy