nfs4_detect_...ion_trunking(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… nfs4_detect_session_trunking(9) β€” like, the kernel API manual bestie πŸ¦‹

okay so this is a page from the Kernel API Manual and it's all about nfs4_detect_session_trunking β€” yes that's the full name, and yes the header is truncated as nfs4_detect_...ion_trunking(9) because even man pages gotta keep it cute and fit on one line πŸ’€


✨ NAME ✨

nfs4_detect_session_trunking β€” literally just checks for session trunking. that's the whole vibe check πŸ”₯


🌸 SYNOPSIS 🌸

int nfs4_detect_session_trunking (struct nfs_client *clp , struct
nfs41_exchange_id_res *res , struct rpc_xprt *xprt );

πŸŽ€ ARGUMENTS πŸŽ€

  • clp β€” the original mount nfs_client. like, the OG, the main character πŸ‘‘
  • res β€” the result structure from an exchange_id that used the original mount nfs_client with a new multi_addr transport. yeah, it's giving "same client, new transport" energy πŸ’«
  • xprt β€” pointer to the transport to add. we're bringing a new one into the group chat 🫢

πŸ’– DESCRIPTION πŸ’–

so this gets called after a successful EXCHANGE_ID on a multi-addr connection. that's the whole setup. and then? upon success, add the transport. slay, that's it ✨

returns zero on success β€” otherwise -EINVAL. no cap, that's the whole return contract πŸ™ˆ


⭐ NOTE ⭐

okay bestie, important detail here πŸ‘€ since the exchange_id for the new multi_addr transport uses the same nfs_client from the original mount, the cl_owner_id is reused β€” which means eir_clientowner is the same. same owner, different transport, iykyk πŸ’…


πŸ‘‘ SEE ALSO πŸ‘‘

kernel file ./fs/nfs/nfs4client.c plus the whole squad:


that's the page, periodt 🌈 and a little sign-off for you: this one lives in ./fs/nfs, dated October 2026 β€” so mark your calendar, bestie πŸ—“οΈπŸ’œ

πŸ“¦ where this page comes from