All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Henriques <luis@igalia.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: fuse-devel <fuse-devel@lists.linux.dev>,
	 linux-fsdevel@vger.kernel.org, John Groves <John@groves.net>,
	 Joanne Koong <joannelkoong@gmail.com>,
	"Darrick J . Wong" <djwong@kernel.org>,
	 Amir Goldstein <amir73il@gmail.com>,
	 Bernd Schubert <bernd@bsbernd.com>,
	 Horst Birthelmer <horst@birthelmer.de>
Subject: Re: [post LSFMM summary] where is fuse going?
Date: Mon, 11 May 2026 17:43:46 +0100	[thread overview]
Message-ID: <87pl313ni5.fsf@igalia.com> (raw)
In-Reply-To: <CAJfpegvXnA1QpmfM9V+3VB470xYDNWH8FV0mBV1R1-HqvjfJ8A@mail.gmail.com> (Miklos Szeredi's message of "Mon, 11 May 2026 17:12:42 +0200")

Hi Miklos,

On Mon, May 11 2026, Miklos Szeredi wrote:

> Please let know what I missed.

Thanks for the summary.  It looks pretty comprehensive to me, the only
things I don't see listed are the FUSE discord and the monthly/biweekly
call.  But that's probably out of the scope of this email.

Also...

[snip]

> COMPOUND REQS: let's add this to fusex.  uAPI is simple, kAPI needs refining.
>
> FILE HANDLES: same: let's add to fusex.

I'd like to clarify this: do you see fusex as some sort of staging area
for features development that would (or could) eventually be merged back
into the "traditional" FUSE?

I'm asking because I got under the impression that file handles in
particular was something that would be desired to have in "traditional"
FUSE (and that's where I would rather have them TBH).  This would, for
example, help unbreak nfs exports.

Cheers,
-- 
Luís


> URING BUFFER MANAGEMENT: there's a disagreement between Joanne and
> Bernd about this.  I think we first need a very high level description
> of each solution and why it's preferred over the other.
>
> LARGE FOLIOS: depends on !strictlimit.  I don't have a good enough
> understanding of writeback throttling to decide whether removing the
> strictlimit requirement for unprivileged fuse is okay or not.  Need
> more analysis.
>
> FUSEX: there was approval for the idea of using this as a uAPI major
> version update.  In other words fusex will gain feature parity with
> legacy fuse, but with a more consistent interface.
>
> MAILING LIST: we have a shiny new one, there was agreement that it's
> sufficient for normal fuse discussion and patch posting, and usually
> there's no need to cross post linux-fsdevel.
>
> Amir asked about how long it took for overlayfs to go upstream.  Well,
> I looked up both fuse and overlayfs:
>
> fuse first release: Nov 2001
> fuse merge: Sep 2005
>
> ovl first patchset: Aug 2010
> ovl merge: Oct 2014
>
> Both 4 years ±2 months.
>
> So don't despair! There's light at the end of the tunnel (and
> hopefully not the oncoming train ;)
>
> Thanks,
> Miklos


  reply	other threads:[~2026-05-11 16:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-11 15:12 [post LSFMM summary] where is fuse going? Miklos Szeredi
2026-05-11 16:43 ` Luis Henriques [this message]
2026-05-11 19:17   ` Horst Birthelmer
2026-05-12  8:46     ` Luis Henriques
2026-05-12  9:57       ` Miklos Szeredi
2026-05-12  9:38   ` Miklos Szeredi
2026-05-11 17:18 ` Amir Goldstein
2026-05-12  3:20   ` Gao Xiang
2026-05-12  7:53     ` Amir Goldstein
2026-05-12 10:00       ` Miklos Szeredi
2026-05-12 21:40         ` Amir Goldstein
2026-05-13  6:57           ` Gao Xiang
2026-05-12  9:52   ` Miklos Szeredi
2026-05-12 20:33     ` Darrick J. Wong
2026-05-12 20:23 ` Darrick J. Wong
2026-05-19  9:01   ` Miklos Szeredi
2026-05-19 11:23     ` Horst Birthelmer
2026-05-19 22:03     ` Darrick J. Wong
2026-05-20 19:24       ` Amir Goldstein
2026-05-20 20:52         ` Darrick J. Wong

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=87pl313ni5.fsf@igalia.com \
    --to=luis@igalia.com \
    --cc=John@groves.net \
    --cc=amir73il@gmail.com \
    --cc=bernd@bsbernd.com \
    --cc=djwong@kernel.org \
    --cc=fuse-devel@lists.linux.dev \
    --cc=horst@birthelmer.de \
    --cc=joannelkoong@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /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.