keyrings.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: David Howells <dhowells@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	dray@redhat.com, Karel Zak <kzak@redhat.com>,
	Miklos Szeredi <mszeredi@redhat.com>,
	Steven Whitehouse <swhiteho@redhat.com>,
	jlayton@redhat.com, Ian Kent <raven@themaw.net>,
	andres@anarazel.de,
	Christian Brauner <christian.brauner@ubuntu.com>,
	keyrings@vger.kernel.org,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] Mount and superblock notifications
Date: Sat, 04 Apr 2020 21:13:03 +0000	[thread overview]
Message-ID: <CAHk-=wghjTM+z_oAATqWOvPa8Lh6BKRtTVMi7hLxo6pbqc+kVg@mail.gmail.com> (raw)
In-Reply-To: <1449543.1585579014@warthog.procyon.org.uk>

On Mon, Mar 30, 2020 at 7:37 AM David Howells <dhowells@redhat.com> wrote:
>
> If you could consider pulling this - or would you prefer it to go through
> Al?  It adds a couple of VFS-related event sources for the general
> notification mechanism:

<y issue with these remains the same it was last time, so I'll just
quote what I said back then:

 "So I no longer hate the implementation, but I do want to see the
  actual user space users come out of the woodwork and try this out for
  their use cases.

  I'd hate to see a new event queue interface that people then can't
  really use due to it not fulfilling their needs, or can't use for some
  other reason."

I want to see somebody step up enough to say "yes, I actually use
this, and have the patches for the user space side, and it helps my
load by 3000%, and here are the numbers, and the event overflow case
isn't an issue because Y"

Or whatever. It doesn't have to be performance, but the separate
discussion I've seen has been about that being the reason for it.

I just don't want it to be a _hypothetical_ reason. I want it to be a
tested reason where people said "yeah, this is easy to use and
actually fixes the problems".

Because if what happens is that when the events overflow, and maybe
people fall back on the old model (or whatever) then that probably
just means that you do better up until a point where you start doing
_worse_ than we used to.

Or people find out that they needed more information anyway, and the
event model doesn't work when you restart your special server because
you've lost the original state. Or any other number of "cool feature,
but I can't really use it".

IOW, I really want to know that yes, the design is what people will
then use and it actually fixes real-world issues.

And it needs to be interesting and pressing enough that those people
actually at least do a working prototype on top of a patch-set that
hasn't made it into the kernel yet.

Now, I realize that other projects won't _upstream_ their support
before the kernel has the infrastructure, so I'm not looking for
_that_ kind of "yeah, look, project XYZ already does this and Red Hat
ships it". No, I'm looking for those outside developers who say more
than "this is a pet peeve of mine with the existing interface". I want
to see some actual use - even if it's just in a development
environment - that shows that it's (a) sufficient and (b) actually
fixes problems.

             Linus

  reply	other threads:[~2020-04-04 21:13 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-30 13:58 Upcoming: Notifications, FS notifications and fsinfo() David Howells
2020-03-30 14:31 ` [GIT PULL] General notification queue and key notifications David Howells
2020-03-31  6:51   ` Stephen Rothwell
2020-06-02 15:55   ` David Howells
2020-06-03  2:15     ` Ian Kent
2020-06-08  0:49       ` Ian Kent
2020-06-10  9:56     ` Christian Brauner
2020-06-10 11:12     ` Karel Zak
2020-06-12 21:32       ` Linus Torvalds
2020-06-12 22:01       ` Linus Torvalds
2020-06-13 13:04       ` David Howells
2020-06-13 16:47         ` Linus Torvalds
2020-06-13 17:03           ` Linus Torvalds
2020-06-13 19:22         ` Miklos Szeredi
2020-06-13 13:24       ` David Howells
2020-06-13 18:00     ` pr-tracker-bot
2020-06-17  1:15     ` Williams, Dan J
2020-06-23 23:38       ` Dan Williams
2020-06-24  0:55       ` David Howells
2020-06-24  1:03         ` Dan Williams
2020-06-24  1:17         ` David Howells
2020-03-30 14:36 ` [GIT PULL] Mount and superblock notifications David Howells
2020-04-04 21:13   ` Linus Torvalds [this message]
2020-04-05 22:52     ` Andres Freund
2020-03-30 14:43 ` [GIT PULL] fsinfo: Filesystem information query David Howells
2020-03-30 20:28 ` Upcoming: Notifications, FS notifications and fsinfo() Miklos Szeredi
2020-03-31  9:21   ` Karel Zak
2020-03-30 21:17 ` Christian Brauner
2020-03-31  5:11   ` Miklos Szeredi
2020-03-31  8:15     ` Christian Brauner
2020-03-31  8:34       ` Miklos Szeredi
2020-03-31  8:34     ` Karel Zak
2020-03-31  8:56       ` Miklos Szeredi
2020-03-31  9:49         ` Karel Zak
2020-03-31 12:25         ` Lennart Poettering
2020-03-31 15:10           ` Miklos Szeredi
2020-03-31 15:24             ` Lennart Poettering
2020-03-31 21:56         ` David Howells
2020-03-31 21:54     ` David Howells
2020-04-01  8:43       ` Karel Zak
2020-03-31  7:22   ` Lennart Poettering
2020-03-31 17:31 ` David Howells
2020-03-31 19:42   ` Miklos Szeredi
2020-03-31 19:47   ` David Howells
2020-03-31 21:14   ` David Howells
2020-03-31 21:23   ` David Howells
2020-03-31 21:52 ` David Howells
2020-04-01  9:04   ` Karel Zak
2020-04-01 13:34     ` Miklos Szeredi
2020-04-01 13:55     ` David Howells
2020-04-01 13:58     ` David Howells
2020-04-01 15:25       ` Miklos Szeredi
2020-04-03  9:11         ` Karel Zak
2020-04-01 16:01       ` David Howells
2020-04-01 16:30         ` Miklos Szeredi
2020-04-02 15:22         ` David Howells
2020-04-02 15:24           ` Miklos Szeredi
2020-04-02 15:42           ` David Howells
2020-04-02 15:24         ` David Howells
2020-04-01 14:41   ` Lennart Poettering
2020-04-01 15:33     ` Miklos Szeredi
2020-04-01 16:06     ` David Howells
2020-04-01 16:40       ` Miklos Szeredi
2020-04-02  2:52         ` Ian Kent
2020-04-02 13:52           ` Miklos Szeredi
2020-04-02 14:36             ` Lennart Poettering
2020-04-02 15:22               ` Miklos Szeredi
2020-04-02 15:28                 ` Lennart Poettering
2020-04-02 15:35                   ` Miklos Szeredi
2020-04-02 15:50                     ` Lennart Poettering
2020-04-02 17:20                       ` Miklos Szeredi
2020-04-03 11:08                         ` Lennart Poettering
2020-04-03 11:48                           ` Miklos Szeredi
2020-04-03 15:01                             ` Lennart Poettering
2020-04-06  9:22                               ` Miklos Szeredi
2020-04-06 17:29                                 ` Lennart Poettering
2020-04-07  2:21                                   ` Ian Kent
2020-04-07 13:59                                     ` Miklos Szeredi
2020-04-07 15:53                                       ` Lennart Poettering
2020-04-07 16:06                                         ` Miklos Szeredi
2020-04-02 15:51                 ` David Howells
2020-04-02 15:56                 ` David Howells
2020-04-03  1:44             ` Ian Kent
2020-04-03 11:11               ` Lennart Poettering
2020-04-03 11:38                 ` Miklos Szeredi
2020-04-03 12:05                   ` Richard Weinberger
2020-04-03 15:12                   ` Lennart Poettering
2020-04-03 20:30                     ` J. Bruce Fields
2020-04-06  8:35                       ` Miklos Szeredi
2020-04-06 16:07                         ` J. Bruce Fields
2020-04-06  9:17                       ` Karel Zak
2020-04-06 16:34                         ` Linus Torvalds
2020-04-06 18:46                           ` J. Bruce Fields
2020-04-06 18:48                           ` Lennart Poettering
2020-04-08  3:36                             ` Linus Torvalds
2020-04-03 15:36                   ` David Howells
2020-04-03 15:41                     ` Lennart Poettering

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='CAHk-=wghjTM+z_oAATqWOvPa8Lh6BKRtTVMi7hLxo6pbqc+kVg@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=andres@anarazel.de \
    --cc=christian.brauner@ubuntu.com \
    --cc=dhowells@redhat.com \
    --cc=dray@redhat.com \
    --cc=jlayton@redhat.com \
    --cc=keyrings@vger.kernel.org \
    --cc=kzak@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mszeredi@redhat.com \
    --cc=raven@themaw.net \
    --cc=swhiteho@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).