public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox