[OpenAFS-devel] GSOC 2026 Application : Add mount point and ACL support to the afsio command-line tool

[Akarshi Sinha]

--0000000000007de546064c9913ab
Content-Type: text/plain; charset="UTF-8"

Dear OpenAFS team,

My name is Akarshi Sinha, and I am a final-year Computer Science
Engineering student with experience in C and Linux systems programming. I
am interested in the afsio enhancements project for GSoC 2026.

Over the past few weeks, I have been going through the codebase. I traced
how the existing subcommands use libafscp to communicate directly with file
servers, and studied the data flow for mount point and ACL operations from
afscp_FetchACL and afscp_StoreACL through the AFSOpaque wire format and
across fs.c and the cache manager. I also mapped where dependency and
parsing issues arise when moving that functionality into afsio. The
libafscp library already handles the RPC layer for both operations, but
there are meaningful gaps in the parsing and dependency structure that the
implementation will need to address.

Before drafting my proposal, I had a few questions:

1. The description mentions enabling cell creation without a kernel module.
Is there a specific sequence of operations you have in mind that afsio
should support end to end?

2. For ACL parsing, I am leaning toward duplicating the logic from fs.c
into afsio to avoid adding liboafs_prot as a new dependency. Would that
approach align with the project's preferences, or is there a cleaner
direction you would recommend?

3. Does the project intend to include mount point removal in addition to
creation? For ACLs, is the goal to support both reading and setting, or
primarily one direction?

4. I did not find existing test infrastructure specific to afsio. Would
establishing a testing approach for the new subcommands be considered in
scope? If so, is there a preferred methodology for testing this kind of
clientless operation?

I would be grateful for any feedback or guidance. Thank you for your time
and consideration.

Warm regards,
Akarshi

--0000000000007de546064c9913ab
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Dear OpenAFS team,<div dir=3D"auto"><br></div><div dir=3D=
"auto">My name is Akarshi Sinha, and I am a final-year Computer Science Eng=
ineering student with experience in C and Linux systems programming. I am i=
nterested in the afsio enhancements project for GSoC 2026.</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">Over the past few weeks, I have been goi=
ng through the codebase. I traced how the existing subcommands use libafscp=
 to communicate directly with file servers, and studied the data flow for m=
ount point and ACL operations from afscp_FetchACL and afscp_StoreACL throug=
h the AFSOpaque wire format and across fs.c and the cache manager. I also m=
apped where dependency and parsing issues arise when moving that functional=
ity into afsio. The libafscp library already handles the RPC layer for both=
 operations, but there are meaningful gaps in the parsing and dependency st=
ructure that the implementation will need to address.</div><div dir=3D"auto=
"><br></div><div dir=3D"auto"><div dir=3D"auto">Before drafting my proposal=
, I had a few questions:</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>1. The description mentions enabling cell creation without a kernel module=
. Is there a specific sequence of operations you have in mind that afsio sh=
ould support end to end?</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>2. For ACL parsing, I am leaning toward duplicating the logic from fs.c in=
to afsio to avoid adding liboafs_prot as a new dependency. Would that appro=
ach align with the project&#39;s preferences, or is there a cleaner directi=
on you would recommend?</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
3. Does the project intend to include mount point removal in addition to cr=
eation? For ACLs, is the goal to support both reading and setting, or prima=
rily one direction?</div><div dir=3D"auto"><br></div><div dir=3D"auto">4. I=
 did not find existing test infrastructure specific to afsio. Would establi=
shing a testing approach for the new subcommands be considered in scope? If=
 so, is there a preferred methodology for testing this kind of clientless o=
peration?</div><div dir=3D"auto"><br></div><div dir=3D"auto">I would be gra=
teful for any feedback or guidance. Thank you for your time and considerati=
on.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Warm regards,</div><=
div dir=3D"auto">Akarshi</div></div></div>

--0000000000007de546064c9913ab--