Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2775614imu; Sun, 11 Nov 2018 00:18:18 -0800 (PST) X-Google-Smtp-Source: AJdET5dzi7ACKHWuxcShgxdbdpjGy++MAZxWOYxRq/awLRu/8Qf8unvABZE+oQbce9PaguhH4TI6 X-Received: by 2002:a63:111c:: with SMTP id g28mr13306497pgl.85.1541924298230; Sun, 11 Nov 2018 00:18:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541924298; cv=none; d=google.com; s=arc-20160816; b=zivx+5d2ytyGa8ptpjvN0ltgCM5cvsNVdvmY7hOykgSq4vweTEfuVWVp8J5HOerdIB qumLydEjkJoNXVo5jt2JVaD4S4Tixt6Cr7DS7/cVeWhrZMdReTjqGPTZ1D1xEL1AVTbV avWiacbGoDfDVpHRDzaj5bO8u2n5s4X9rICwVZF9iHO/AIIDFYxhuTIqeUaYyW4NaEoN wFGTXaGk02NqOioMM01oARE2bD1f2NB7J86NCQLhgrG3iP7ZTSctR+NVNk8aNbOBT/Vd 9xbupNrxymeQJhEDMb7xAGSkRYOlnC/INb2IjLwZ46+0nbVSJjPSnzkKYcshCkwkUJnm InJg== 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=vSLkcHVCOdGu7r1fTX9YVqZgLngTHLvFElRZ7JM5vH4=; b=xu0QWTOGYRe8jUYfjyp91PGdf+SmrhOeLO7Ul2ovJ9HaPiNrXnUGY1QBNJRhT0rdlM lguvyNiRCs/JHLFeMoqOFKY2vzLzGkhtVh20VYjsjUoZBmFn5FV0/42cgvwzEvyZvE7+ 8ZWBsnrsHYxPoPaAJhL+14Fg5h9kurrEt3PtC+KndZpvFu+kM7vQKvQbH1VbfdoOGIoh fdlf1f+XIHN6WNJGML+Dm+FBxLEdKcdiQnPtBQkxO5Q7fEKp5l/MdrjA/QoIMulARIo4 PiYZwwBKnbIwGnzfyCsTa8X5sdmSEzDKVuxZfVn7Yxy20NZdzXNon3pdfkBjMPTkTAzm Pt+A== 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 k192-v6si12627839pgc.415.2018.11.11.00.18.02; Sun, 11 Nov 2018 00:18:18 -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 S1727462AbeKKSFe (ORCPT + 99 others); Sun, 11 Nov 2018 13:05:34 -0500 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:41825 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727055AbeKKSFe (ORCPT ); Sun, 11 Nov 2018 13:05:34 -0500 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id wAB8HQRa030289; Sun, 11 Nov 2018 09:17:26 +0100 Date: Sun, 11 Nov 2018 09:17:25 +0100 From: Willy Tarreau To: "Michael Kerrisk (man-pages)" Cc: Daniel Colascione , linux-kernel , Joel Fernandes , Linux API , Vlastimil Babka , Florian Weimer , "Carlos O'Donell" , "libc-alpha@sourceware.org" Subject: Re: Official Linux system wrapper library? Message-ID: <20181111081725.GA30248@1wt.eu> References: 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 Sun, Nov 11, 2018 at 07:55:30AM +0100, Michael Kerrisk (man-pages) wrote: > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=6399 is a > longstanding example. This one was a sad read and shows that applications will continue to suffer from glibc's prehistorical view on operating systems and will continue to have to define their own syscall wrappers to exploit the full potential of the modern operating systems they execute on. This reminds me when one had to write their own spinlocks and atomics many years ago. Seeing comments suggesting an application should open /proc/$PID makes me really wonder if people actually want to use slow and insecure applications designed this way. Bah, after all, this wipes quite a bit of the shame I feel every time I do something to bypass it :-/ The sad thing is that the energy wasted arguing in the bug above could have been better spent designing and implementing a generic solution to expose syscalls without depending on glibc's politics anymore. Willy