Re: [RFC] inetd(8) changes proposal

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> 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		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B