Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2292640imu; Sat, 10 Nov 2018 11:34:30 -0800 (PST) X-Google-Smtp-Source: AJdET5eIaDPsi6rCRFqIvDjCfj/jtNI7RXBcB5ufu+fCnRwN3wehMv418Lj3jKq7MCCUZacdxPQr X-Received: by 2002:a63:4c6:: with SMTP id 189mr12080122pge.391.1541878470118; Sat, 10 Nov 2018 11:34:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541878470; cv=none; d=google.com; s=arc-20160816; b=X5vAB8e32NVT0X/sPRM3Xn1uSn/Hh07sdraAouzkVeqMd3fuXwTmYmVNriDcoMJb6a E5QdNxa8ovZxQtiEfd+Ttm7cEyGTqf0dsfpbfdgZA+ijHVoEM7bKQtolrp1N1oEwaLXe nntfa2ByIQDejS7NqedMx+fh/n2s26TnIMH959wOUzc8cZw82kECFIUxpDPnfEtN29K/ PPby8CEn4cLKBlPY+18xSR3t8e05kr7TThLxRi6+ArVm77d8iwPbr2auEwbEH1fZ5+Qp 2SppH/z+Shoi+SvHU8HYlZwP4HBHpycGIWsWmOcUoiFXceq0XGXEcxXpFfBRX48vQnce VW/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=a3Ao6b9OL2EJuclUnDmqtY7gSrjYwrZPx4VKyypefuU=; b=NYI8PgaePU16i9KiAfLhHxeftRMubJ1pRpWr1zEmS7Kf8+e6YIInzJBKe2G4+fI5kO 8tyuFLLi8BQVWbxnmpkBqHqKIT4GlA8eanp3nJsXas/SsKp5doRFXmIHFwuNsYf7yCEO DAqAlXrqt0u46hP4d6jFKdNhfLQpBehxiU58Kw7MfcXtHNLsCcoUGnvTnfm4Z86H5Yed neulmpN3pIo1sXW2gR8yQAMKVeEyrIqmJfdbx7k6nIIHO27HtRDLjjgOidWOYKbpCKh+ 5J1k3MYgYBhz8gtNfxfSWaApWjyYsqytmDGF5OpzizyDn7/iaTDHkK85CHonn2DsjMPv 1Vkg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u5si10131803pgi.146.2018.11.10.11.33.58; Sat, 10 Nov 2018 11:34:30 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726407AbeKKFTa (ORCPT + 99 others); Sun, 11 Nov 2018 00:19:30 -0500 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:41680 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726258AbeKKFTa (ORCPT ); Sun, 11 Nov 2018 00:19:30 -0500 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id wAAJXMBY021221; Sat, 10 Nov 2018 20:33:22 +0100 Date: Sat, 10 Nov 2018 20:33:22 +0100 From: Willy Tarreau To: Daniel Colascione Cc: linux-kernel , Joel Fernandes , Linux API Subject: Re: Official Linux system wrapper library? Message-ID: <20181110193322.GB21185@1wt.eu> References: <20181110190132.GA21185@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 10, 2018 at 11:06:45AM -0800, Daniel Colascione wrote: > Reminds me of LSS: https://chromium.googlesource.com/linux-syscall-support/ Interesting, thanks for the link, I would probably not have started mine had I known this one :-) > I'm not a fan of this approach for general-purpose use. There's value > in having *some* common function-level indirection before actually > issuing system calls, e.g., for LD_PRELOAD stuff. I'm not speaking about general purpose replacement but more about general purpose low level functions that glibc wrappers can safely use and expose by default. This way general purpose applications would still use glibc and those willing to use a lower level could do it more easily by accessing the lower layer, without having to define their own syscalls. If I could do something like this in my code : #ifndef HAVE_SYSCALL_SPLICE // exposed by glibc # ifdef __linux_splice // exposed by kernel header # define splice __linux_splice # else # error "no splice exposed by either libc or kernel headers" # endif #endif It would be easier, safer and cleaner than what I've used to do before : #if !defined(HAVE_SYSCALL_SPLICE) && defined(__NR_splice) static inline _syscall6(int, splice, int, fdin, loff_t *, off_in, int, fdout, loff_t *, off_out, size_t, len, unsigned long, flags); #endif Willy