From: "Theodore Tso" <tytso@mit.edu>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 0/7] fix up issues from djwong/fuse4fs-fork
Date: Wed, 6 May 2026 11:28:58 +0200 [thread overview]
Message-ID: <20260506092858.GC49070@macsyma.local> (raw)
In-Reply-To: <20260505225635.GT7765@frogsfrogsfrogs>
On Tue, May 05, 2026 at 03:56:35PM -0700, Darrick J. Wong wrote:
> FUSE kABI 7.20 added FUSE_AUTO_INVAL_DATA, which is bit 12. It looks to
> me as though they decided to add their own MacOS-specific feature flags
> at the end of the u32 want field. Then Linux FUSE added 11 more feature
> flags, at which point they unthinkingly ported over FUSE_CACHE_SYMLINKS,
> which collides with FUSE_DARWIN_ACCESS_EXT. Apparently nobody on the
> macfuse end noticed, so on your machine you're getting whatever
> "ACCESS_EXT" does.
Yeah....
What MacFuse needs to do is to steal some extra fields from struct
fuse_init_in and fuse_init_out for the darwin-specific capabilities.
It turns out it already has conn->{want,capable}_darwin, but there's
no way to pass it in and out of op_init....
#ifdef __APPLE__
/*
* TODO(bf)
*
* Resolve conflict with vanilla API. We need a separate field flags for
* Darwin-only flags. As long as we don't support anything beyond ABI
* version 7.19 on the kernel-side this should not be an issue, though.
* We need to clean this up when moving to 7.20 or later.
*/
if (se->conn.want_darwin & FUSE_DARWIN_CAP_ACCESS_EXT)
outargflags |= FUSE_DARWIN_ACCESS_EXT;
So I *guess* what MacFuse needs to do is to do something like:
struct fuse_init_in {
uint32_t major;
uint32_t minor;
uint32_t max_readahead;
uint32_t flags;
uint32_t flags2;
uint32_t unused[9];
uint32_t darwin_flags;
uint32_t darwin_flags2;
};
am I right in understanding that fuse_*_{in,out} is private between
the OS's libfuse and OS's fuse driver or kernel extension, so
it's not disastrous for fuse_kernel.h for Mac and Linux to drift?
> Does this work?
>
> /* MacFUSE overlays feature bits with LinuxFUSE, this is fcked up */
> #if defined(FUSE_CAP_CACHE_SYMLINKS) && !defined(FUSE_CACHE_SYMLINKS)
> fuse_set_feature_flag(conn, FUSE_CAP_CACHE_SYMLINKS);
> #endif
What I'm thinking about doing is adding at the beginning of
fuse[24]fs.c:
#ifdef __APPLE__
/*
* Sigh.... MacFuse is overloading the top bits of the flags field of
* struct fuse_init_{out} so we have to avoid using these capability
* flags until this gets fixed in MacFUSE
*/
#undef FUSE_CACHE_SYMLINKS
#undef FUSE_NO_OPENDIR_SUPPORT
#undef FUSE_EXPLICIT_INVAL_DATA
#undef FUSE_MAP_ALIGNMENT
#undef FUSE_SUBMOUNTS
#undef FUSE_HANDLE_KILLPRIV_V2
#undef FUSE_SETXATTR_EXT
#undef FUSE_INIT_EXT
#endif
- Ted
next prev parent reply other threads:[~2026-05-06 9:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-04 23:32 [PATCH 0/7] fix up issues from djwong/fuse4fs-fork Theodore Ts'o
2026-05-04 23:32 ` [PATCH 1/7] libsupport: drop xbitops.h and define fls() if necessary Theodore Ts'o
2026-05-05 0:11 ` Darrick J. Wong
2026-05-04 23:32 ` [PATCH 2/7] configure.ac: fix disable fuse2fs/fuse4fs by default path Theodore Ts'o
2026-05-05 0:13 ` Darrick J. Wong
2026-05-04 23:32 ` [PATCH 3/7] libsupport: don't use bzero in cache.c Theodore Ts'o
2026-05-05 0:15 ` Darrick J. Wong
2026-05-04 23:32 ` [PATCH 4/7] fuse[24]fs: suppress clang warnings which were breaking the github CI Theodore Ts'o
2026-05-05 0:20 ` Darrick J. Wong
2026-05-04 23:32 ` [PATCH 5/7] libsupport: remove the LIST_HEAD macro from list.h Theodore Ts'o
2026-05-05 0:20 ` Darrick J. Wong
2026-05-04 23:33 ` [PATCH 6/7] libsupport: fix gcc -Wall warnings Theodore Ts'o
2026-05-05 0:20 ` Darrick J. Wong
2026-05-04 23:33 ` [PATCH 7/7] fuse2fs: fix uninitialized variable warnings Theodore Ts'o
2026-05-05 0:26 ` Darrick J. Wong
2026-05-05 0:08 ` [PATCH 0/7] fix up issues from djwong/fuse4fs-fork Darrick J. Wong
2026-05-05 7:21 ` Theodore Tso
2026-05-05 15:58 ` Darrick J. Wong
2026-05-05 22:04 ` Theodore Tso
2026-05-05 22:56 ` Darrick J. Wong
2026-05-06 9:28 ` Theodore Tso [this message]
2026-05-06 14:34 ` Darrick J. Wong
2026-05-06 15:08 ` Theodore Tso
2026-05-06 16:39 ` 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=20260506092858.GC49070@macsyma.local \
--to=tytso@mit.edu \
--cc=djwong@kernel.org \
--cc=linux-ext4@vger.kernel.org \
/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.