Re: [GIT PULL 3/4] fuse2fs: improve block and inode caching

["Darrick J. Wong" <djwong@kernel.org>]

On Tue, Sep 22, 2026 at 10:00:57PM -0400, Theodore Tso wrote:
> On Fri, Sep 11, 2026 at 11:42:15PM -0500, Darrick J. Wong wrote:
> > 
> > This series ports the libext2fs inode cache to the new cache.c hashtable
> > code that was added for fuse4fs unlinked file support and improves on
> > the UNIX I/O manager's block cache by adding a new I/O manager that does
> > its own caching.  Now we no longer have statically sized buffer caching
> > for the two fuse servers.
> 
> The problem is that cache.c is in lib/support, and my long-standing
> rule is that the interface of lib/support is not guaranteed to be
> stable, and hence libsupport.a is *not* built as a shared library.
> For this reason, we can't allow libext2fs to link against
> libsupport.a.  If we do, then the interfaces in libsupport.a will leak
> into the libext2fs namespace.  This means that applications that link
> against libext2fs might accidentally use it.

Ah, right, I forgot that non-static functions can leak out that way.

> If we ever change a function in libsupport, and it's also in
> libext2fs, then a binary which links against the newer version of the
> function in libsupport.a, but then the binary happens to use
> libext2fs.so.2 with the older version of that function.... well,
> hilarity can ensue.  (Especially with Linux's ELF shared library,
> things are OK with AIX shared library and how it handles shared
> library linking, but that's another story.)
> 
> So there are a couple of ways we can handle this.
> 
> 1) We could #include cache.c with some kind of #define hack to make
>    all of the functions marked to be static.

Eww....

> 2). We could move cache.c to lib/ext2fs and rename all of the
> functions to something like _libext2fs_cache_xxx (to avoid namespace
> collisions), or if we think we are happy publishing it as a public,
> stable interface that is used by fuse4fs, we could use
> libext2fs_cache_xxx.
> 
> What do you think?

Hmmm.  I guess it's really up to you as the maintainer.  I was trying to
avoid exporting more things in libext2fs, but we could just move it
there if you're ok with having more API surface.

The funny part would be to export it and then try to convince the
xfsprogs maintainers to make xfsprogs depend on libext2fs to reduce code
duplication <duck>

--D