Re: [LSF/MM/BPF TOPIC] Where is fuse going? API cleanup, restructuring and more

[Gao Xiang <hsiangkao@linux.alibaba.com>]

On 2026/3/22 11:25, Demi Marie Obenour wrote:

> The only exceptions are if the filesystem is incredibly simple
> or formal methods are used, and neither is the case for existing
> filesystems in the Linux kernel.

Again, first, I don't think "simple" is a helpful and descriptive
word out of this kind of area:

"simple" formats are all formats just archive the filesystem
data and metadata, but without any more use cases. No simpler
than that, because you need to tell vfs the file (meta)data
(even the file data is the garbage data), otherwise they won't
be called as filesystems.

So why we always fall into comparing which archive filesystem
is simpler than others unless some bad buggy designs in those
"simple" filesystems.

Here, I can definitely say _EROFS uncompressed format_ fits
this kind of area, and I will write down formally later if each
on-disk field has unexpected values like garbage numbers, what
the outcome.  And the final goal is to allow EROFS uncompressed
format can be mounted as the "root" into totally isolated
user/mount namespaces since it's really useful and no practical
risk.

If any other kernel filesystem maintainers say that they can do
the same , why not also allow them do the same thing? I don't
think it's a reasonable policy that "due to EXT4, XFS, BtrFS
communities say that they cannot tolerate the inconsistent
consequence, any other kernel filesystem should follow the
same policy even they don't have such issue by design."

In other words, does TCP/IP protocol simple? and is there no
simplier protocol for network data? I don't think so, but why
untrusted network data can be parsed in the kernel?  Does
TCP/IP kernel implementation already bugless?

Quite confusing.

Thanks,
Gao Xiang