From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5667 invoked by alias); 30 Mar 2017 17:08:13 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 5648 invoked by uid 89); 30 Mar 2017 17:08:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=badly, incredibly X-HELO: mail-it0-f51.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=MfbCZ+YOiBMAF7KF7W4eMHqrpjHxRBdCIO4L4VStXKw=; b=D2AfwXgPqJ+MG+gBSx7ZRSB51RfnL6FzdcldEo23gCjHpL2QvGI8QzshszfnLLzr2O gYeIRxwkJgfPoN44a4M5lBwhHIuxcYfcn87pNK+ZQGOc1J1usB2YxAJlYOmFeFzjxCPI vMfQaUuKmN6FmDr5rf+4Mra3xL1OdRoEQPKa4WzOdxHkoR8DDrNI9GVBkWP5NLqx+Hsz 2wHgMv3+Ba8Zx4XlfOWB6SqqAMskw+qfzun4brQlFdoXGkT9zGUjJXjY5AdRfhgHOYK+ t8jXe75NxLBF8ZmmqUiqZBLzL+oVzgy+25zg8lGw0Joz/J3fCUwKiaVejQowKH6unPFk z5+Q== X-Gm-Message-State: AFeK/H0WVpI6QrIrpUQXvDCoEBjtR1HvoeITgMnbqZ2ocUDNudZ8Tu5C3m4G4vz66n0R/jwrA6svTmp4t+nZgQ== X-Received: by 10.36.144.132 with SMTP id x126mr5372048itd.35.1490893690948; Thu, 30 Mar 2017 10:08:10 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20170330163327.23920-1-hch@lst.de> References: <20170330163327.23920-1-hch@lst.de> From: Linus Torvalds Date: Thu, 30 Mar 2017 17:08:00 -0000 Message-ID: Subject: Re: RFC: reject unknown open flags To: Christoph Hellwig Cc: Alexander Viro , Linux API , linux-fsdevel , Linux Kernel Mailing List , libc-alpha Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2017-03/txt/msg00690.txt.bz2 On Thu, Mar 30, 2017 at 9:33 AM, Christoph Hellwig wrote: This really harms > when adding new flags, because applications can't just probe for the > flag to actually work. Side note: this whole argument is also incredibly idiotic from the very beginning, regardless of the backwards compatibility issue. But probing for flags is why we *could* add things like O_NOATIME etc - exactly because it "just worked" with old kernels, and people could just use the new flags knowing that it was a no-op on old kernels. The whole concept of "probing for supported features" is very suspect. It's a bad bad idea. Don't do it. What kind of new flag did you even have in mind that would have such broken semantics that it would completely change the other flags? Becuase now I'm starting to think that the whole series has an even deeper bug: stupid new features that were badly thought out and not even described. Linus