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.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, FSL_HELO_FAKE,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 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 86E80C3A5A2 for ; Tue, 10 Sep 2019 06:37:41 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (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 06F4720872 for ; Tue, 10 Sep 2019 06:37:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="RT2CZzYf" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 06F4720872 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 46SFhH5SV1zDqXV for ; Tue, 10 Sep 2019 16:37:35 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gmail.com (client-ip=2a00:1450:4864:20::441; helo=mail-wr1-x441.google.com; envelope-from=mingo.kernel.org@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="RT2CZzYf"; dkim-atps=neutral Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 46SFf74lFYzDqVv for ; Tue, 10 Sep 2019 16:35:40 +1000 (AEST) Received: by mail-wr1-x441.google.com with SMTP id t16so17623758wra.6 for ; Mon, 09 Sep 2019 23:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=9uC8BSyBqqvpBHr+UBJrMjpTjeLS9eaSkiimfXBOGmI=; b=RT2CZzYflWq0hJIviZ1qNiz7T8GR4+WUrisMZXe3m9cauTkqIyyVGGFPULrde7A02W tj7FplDkEllE02owPbUYDzEtapP1C48use/4kFc7fZZmFt/DdDZTI55D8qvOaO2r24Ne q4FNPrvlkjfx+lYW3lSYcZ69k2e463dcG9Y4rn+PPa/Glpr++eDfgJ8gFO5kdGQ+ZZAk nXhnUxrt/DhKZTkCCWYef7FPywkEzNn0z8LUShNXRMIkZZwOG/G3kJoXGIwG7zGeC0aS TI+DZ2QVgsA7VVK9EZCvbN7bPdpk9PkNXAPdUVWeWNcFfO4yiY8K5tj2pJUrGvJYeUSW 9/rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=9uC8BSyBqqvpBHr+UBJrMjpTjeLS9eaSkiimfXBOGmI=; b=hH7cJmzrb4qxU6y1LKQ/4hyQc+FtYW0iDPD89t1+8+tF0KuK1qx1PDBxD7sRrrAK+K 23LF3UzjdzJyspa9Nbxdqgkoa1EVbVaNyBWN12VVQBaDbMzESZqPNrPVvgGXdtQ09J7B J6tWLiDssJn7acEg4pe1GWhZQZm1Vlowj+9T0SD3l4km77aMpedh9EdZ9ZLc57Dg/jyE crzXBJ2S31ZwfDF8WuuleKbDYm9pyOZOpYBxX8O2kwDF96MphIjajHsNlOoqKU4XntXj fhkduLfVT7n+nftLsIqjjsV2ZOF9R6P1reUk/gTfs52eJQ+2VP6NcPYtB+52ae/a1XgU xDiQ== X-Gm-Message-State: APjAAAWdGCgjda8P5SGM3unZOnzaMM03MXUC858dtbOgyVRYLZjwx4NY 1btPrZOpNkQrr6i1MwIWhLE= X-Google-Smtp-Source: APXvYqw8XHm4leFwnC6sWR8BjhyMsv0e/YjeclMhzrktUUdT/wG1WxzN3IHekSLZEGkf3MnHklk0qA== X-Received: by 2002:a5d:6b0f:: with SMTP id v15mr22340960wrw.19.1568097336267; Mon, 09 Sep 2019 23:35:36 -0700 (PDT) Received: from gmail.com (2E8B0CD5.catv.pool.telekom.hu. [46.139.12.213]) by smtp.gmail.com with ESMTPSA id u22sm32329249wru.72.2019.09.09.23.35.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Sep 2019 23:35:35 -0700 (PDT) Date: Tue, 10 Sep 2019 08:35:32 +0200 From: Ingo Molnar To: Linus Torvalds Subject: Re: [PATCH v12 11/12] open: openat2(2) syscall Message-ID: <20190910063532.GB1579@gmail.com> References: <20190904201933.10736-1-cyphar@cyphar.com> <20190904201933.10736-12-cyphar@cyphar.com> <7236f382d72130f2afbbe8940e72cc67e5c6dce0.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-ia64@vger.kernel.org, Linux-sh list , Peter Zijlstra , Rasmus Villemoes , Alexei Starovoitov , Linux List Kernel Mailing , David Howells , "open list:KERNEL SELFTEST FRAMEWORK" , sparclinux@vger.kernel.org, Shuah Khan , linux-arch , linux-s390 , Tycho Andersen , Aleksa Sarai , Jiri Olsa , Alexander Shishkin , Ingo Molnar , Linux ARM , linux-mips@vger.kernel.org, linux-xtensa@linux-xtensa.org, Kees Cook , Arnd Bergmann , Jann Horn , Aleksa Sarai , Al Viro , Andy Lutomirski , Shuah Khan , Namhyung Kim , David Drysdale , Christian Brauner , "J. Bruce Fields" , linux-parisc@vger.kernel.org, linux-m68k , Linux API , Chanho Min , Jeff Layton , Oleg Nesterov , Andy Lutomirski , Eric Biederman , alpha , linux-fsdevel , Andrew Morton , linuxppc-dev@lists.ozlabs.org, Linux Containers Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" * Linus Torvalds wrote: > On Sat, Sep 7, 2019 at 10:42 AM Andy Lutomirski wrote: > > > > Linus, you rejected resolveat() because you wanted a *nice* API > > No. I rejected resoveat() because it was a completely broken garbage > API that couldn't do even basic stuff right (like O_CREAT). > > We have a ton of flag space in the new openat2() model, we might as > well leave the old flags alone that people are (a) used to and (b) we > have code to support _anyway_. > > Making up a new flag namespace is only going to cause us - and users - > more work, and more confusion. For no actual advantage. It's not going > to be "cleaner". It's just going to be worse. I suspect there is a "add a clean new flags namespace" analogy to the classic "add a clean new standard" XKCD: https://xkcd.com/927/ Thanks, Ingo