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
