[OpenAFS-devel] [GSoC 2026 Applicant] Abinash Singh ( for OpenAFS Low-Level FUSE client)

[Abinash Singh]

Hi Mike,

I have gone through the project description and the codebase, and this
is what I understood.

The existing OpenAFS FUSE client uses fuse_operations and handles
requests via libuafs. libuafs operates entirely in userspace and
exposes path-based interfaces.

For this project, since we are targeting the low-level FUSE API
(fuse_lowlevel_ops), the interaction model changes from path-based to
inode-based. Internally, OpenAFS already uses vnodes I think.
Please correct me if I have misunderstood anything.

I had a couple of questions regarding the implementation:

Does libuafs expose vnode-based interfaces(I couldn't see any), or are
vnodes only used internally within the cache manager?
If vnode-level access is available (or can be reasonably exposed),
then it seems we could implement a thin FUSE backend (similar in
spirit to something like afsd_fuse.c) that maps fuse_ino_t to vnodes
and forwards operations accordingly.
If such interfaces are not available, would the expectation be to
introduce a new layer or extend libuafs to support inode-style
operations?

If vnode-level access is available internally, I will try to build a
small prototype to validate this approach and then proceed with a more
detailed proposal.

Thanks Mike
Abinash