Re: git: 79d0f4474653 - main - rpcbind: Ensure krpc is present.

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

My only concern is that it would require restart of rpcbind, if sysadmin
decides to configure NFS later after startup.

-- 
Gleb Smirnoff