From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933482AbdC3RIO (ORCPT ); Thu, 30 Mar 2017 13:08:14 -0400 Received: from mail-it0-f46.google.com ([209.85.214.46]:34025 "EHLO mail-it0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750766AbdC3RIM (ORCPT ); Thu, 30 Mar 2017 13:08:12 -0400 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 10:08:10 -0700 X-Google-Sender-Auth: 9iLtP87iI9qy9hFDNaLwDjP8QxI 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 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: RFC: reject unknown open flags Date: Thu, 30 Mar 2017 10:08:10 -0700 Message-ID: References: <20170330163327.23920-1-hch@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <20170330163327.23920-1-hch-jcswGhMUV9g@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Christoph Hellwig Cc: Alexander Viro , Linux API , linux-fsdevel , Linux Kernel Mailing List , libc-alpha List-Id: linux-api@vger.kernel.org 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