On Mon, Jun 09, 2025 at 01:51:15PM -0700, Gleb Smirnoff wrote: > On Mon, Jun 09, 2025 at 01:28:30PM -0700, Rick Macklem wrote: > R> My vague recollection (I'll admit I cannot be bothered looking at the > R> older code) > R> is that rpcbind would accept queries on a AF_LOCAL (unix domain) socket for > R> local RPC processes. > R> > R> glebius@ does not want RPCs to be done over AF_LOCAL sockets (he would > R> have to explain why), so he created an RPC layer in the krpc for netlink > as an > R> alternative and converted all utilities that were doing RPCs over AF_LOCAL > R> sockets to use it. > > Not exactly. I don't want kernel RPC to userland to use AF_LOCAL. A process to > a process RPC of course continues to use AF_LOCAL. > > What would be better for rpcbind: to skip providing kernel RPC services if > krpc(4) not detected at startup, or to autoload krpc? The latter makes it > safe > for a scenario when NFS is instantiated at a later runtime of a machine, when > rpcbind already runs. The former scenario would require a restart of rpcbind. >
IMO rpcbind must not load any modules. It should communicate with krpc if available. The krpc load is the global system policy decision, it should be handled in rc scripts, as it is common for such decisions. The loading would be enabled if some component requires krpc, which means if nfsd enabled. It would be ordered before rpcbind startup, of course.
