> But that's independent of the signal used to make it happen, [...] > Personally I'd probably pick a different signal for that, but I am > not sure which.
I have long felt that having only two uncommitted signals (SIGUSR1 and SIGUSR2) is way too few. I've also long wanted a way to contact processes by PID. Something like sockets where addresses are process IDs. A while ago, I finally sat down to do something about that. I eventually came to the conclusion that sockets would not do, not because of any conceptual problem but simply because the internal infrastructure involved was incompatible with the design goals I had. (It's possible the socket API design _is_ incompatible with my design goals, but I found the internal issues before I became convinced of that.) So I added a new file descriptor type (well, semi-new; they're DTYPE_MISC) and a new syscall (pidconn) to do the analogs of socket+listen and socket+connect and a few other relevant things. The relevance to this thread is that the way I'd handle this is to give inetd a(n optional) pidconn listener via which it could be told to dump its config, either to the pidconn connection or to a file whose name is specified in the command. Assuming NetBSD isn't interested in going that far, perhaps it would be reasonable to have a config-file syntax which specifies a listening point (AF_LOCAL, AF_INET, AF_INET6, whatever) via which it could be similarly commanded? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
