Re: [RFC] inetd(8) changes proposal

[tlaronde%polynum.com@localhost]

Le Wed, May 31, 2023 at 07:50:03AM -0400, Mouse a écrit :
> >> So I added a new file descriptor type (well, semi-new; they're
> >> DTYPE_MISC) and a new syscall (pidconn) [...]
> 
> > In this area (as others, in fact), the Plan9 solution is quite
> > elegant (and consistent with the whole design): in the /proc/
> > directory, the process has its directory /proc/$pid/, under which
> > there is "ctl" file to which one can write textual messages to
> > control the process:
> 
> > echo $cmd >/proc/$pid/ctl
> 
> That is unidirectional communication.  pidconn is bidirectional.  Aside
> from that, how does the process (a) notice that this has been done and
> (b) get the string ($cmd in the above) to act on it?

I haven't much time to spend with Plan9---to my regrets when it comes to
mastering the concepts---so take the following with a grain of salt:

Controling the process can be made by writing to the "ctl" file (this
does what some Unix signals do).

Other Unix like signals can be emulated via the use of notes. There
is also a "note" file that allows to write to the file (for notes
delivered to the corresponding process).

And if bi-directional IPC is wanted, it can be done at user-level with
the plumber that allows to "receive, examine, rewrite and dispatch
messages between programs" as long as the program allows to be plumbed
(prepared to read and write from conventionally named file in the
namespace). (It does multiplexing too; it is not only 1<->1.)

In fact, one can do the same thing probably with Unix. The difference is
that the facilities are offered by the system and a lot is leveraged by
the manipulation of the namespace (everything can write to "/tmp" except
that what corresponds to "/tmp" for a user is different from what is
used by another one).

> 
> The procfs I have has a ctl file, but it is ptrace-style control, not
> communication a la pidconn (which is optional, more like sockets).  It
> also appears to have vanished by 9.1.  Besides those, I'm not sure how
> I feel about depending on procfs.

Well proc/ in Plan9 is not an external addition. All this machinery is
the core of the system. This is why some concepts of Plan9 have been
adapted in Unix, but others could not so easily be adapted because they
depend too much on things done rather differently and in the core.

But the concept of having well-known file names to communicate
with a process is appealing and to not have to set the communication
channels in every program but just to prepare to use them if the program
wants too, is a bonus.
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C