From: Linus Torvalds <torvalds@linux-foundation.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Linux API <linux-api@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
libc-alpha <libc-alpha@sourceware.org>
Subject: Re: RFC: reject unknown open flags
Date: Thu, 30 Mar 2017 10:08:10 -0700 [thread overview]
Message-ID: <CA+55aFw92r4h4sNW41ifs31ixdZpNmaxY23KthB9R-LXNm7p-w@mail.gmail.com> (raw)
In-Reply-To: <20170330163327.23920-1-hch@lst.de>
On Thu, Mar 30, 2017 at 9:33 AM, Christoph Hellwig <hch@lst.de> 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
WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
To: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Cc: Alexander Viro
<viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-fsdevel
<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux Kernel Mailing List
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
libc-alpha <libc-alpha-9JcytcrH/bA+uJoB2kUjGw@public.gmane.org>
Subject: Re: RFC: reject unknown open flags
Date: Thu, 30 Mar 2017 10:08:10 -0700 [thread overview]
Message-ID: <CA+55aFw92r4h4sNW41ifs31ixdZpNmaxY23KthB9R-LXNm7p-w@mail.gmail.com> (raw)
In-Reply-To: <20170330163327.23920-1-hch-jcswGhMUV9g@public.gmane.org>
On Thu, Mar 30, 2017 at 9:33 AM, Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org> 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
next prev parent reply other threads:[~2017-03-30 17:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-30 16:33 RFC: reject unknown open flags Christoph Hellwig
2017-03-30 16:33 ` Christoph Hellwig
2017-03-30 16:33 ` [PATCH 1/2] fs: add a VALID_OPEN_FLAGS Christoph Hellwig
2017-03-30 16:33 ` [PATCH 2/2] fs: reject unknown open flags Christoph Hellwig
2017-03-30 17:03 ` Linus Torvalds
2017-03-30 17:03 ` Linus Torvalds
2017-03-30 17:08 ` Linus Torvalds [this message]
2017-03-30 17:08 ` RFC: " Linus Torvalds
2017-03-30 17:21 ` Christoph Hellwig
2017-03-30 17:21 ` Christoph Hellwig
2017-03-30 18:19 ` Linus Torvalds
2017-03-30 18:19 ` Linus Torvalds
2017-03-30 18:26 ` Christoph Hellwig
2017-03-30 18:26 ` Christoph Hellwig
2017-03-30 18:45 ` Linus Torvalds
2017-03-30 18:45 ` Linus Torvalds
2017-03-30 20:05 ` Boaz Harrosh
2017-03-30 19:02 ` Paul Eggert
2017-03-30 19:14 ` Linus Torvalds
2017-03-30 19:22 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+55aFw92r4h4sNW41ifs31ixdZpNmaxY23KthB9R-LXNm7p-w@mail.gmail.com \
--to=torvalds@linux-foundation.org \
--cc=hch@lst.de \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.