This is a reply to the first of two of Julian's recent messages. On Friday, March 14, 2025 4:26:30 AM UTC Julian Elischer wrote: > On 1/28/25 12:09 AM, Mark Johnston wrote: > > On Sat, Jan 25, 2025 at 08:44:25PM +0000, Paul Vixie wrote: > >> does anyone remember why the FIB of a socket or process cannot be > >> discovered from user mode? lack of motivation -- or deliberate design > >> decision? > That was probably me. > I probably just didn't need it for my case and didn't spend time on it.
KK. I have a need now. > > ... > > > > So, an application already knows the FIB number of any given socket, > > since it can find its own FIB number, and new sockets always inherit the > > FIB number of the process or the listening socket. Therefore, I believe > > there's no reason not to provide an explicit mechanism to query the FIB > > number. > > I believe so.. Not all sockets within a process are created within that process. When stdin, stdout, and stderr are pty's or pipes, they predate the process, and have no FIB of their own since they aren't sockets. Therefore the process FIB in this case has to be set after fork and before exec by the parent, so that work done within this process is within the FIB that only the parent would otherwise know about. I expect to teach sshd, http, and nginx to look at the FIB of its network socket (which after fibnum2 will not always be that of the listener socket) and then setfib() the forked process FIB to this value before execing the shell or command. Obviously that subprocess will be able to setfib() to some other value if so desired, but the default FIB for the shell and its subprocesses should be the same as for the network socket. For this I do not need a getfib() syscall but I will need an SO_FIB socket option which would allow both setting and getting. We'll have to leave SO_SETFIB for ABI/API stability reasons, of course. -- Paul Vixie
