anyone want to ok this (or better yet, fix themselves)?
jmc
On Fri, Sep 14, 2018 at 01:57:13PM -0700, Geoff Hill wrote:
> The imsg_init(3) man page currently doesn't make it clear whether
> this library can be used for remote communication.
>
> The current text reads:
>
> The imsg functions provide a simple mechanism for communication
> between processes using sockets. Each transmitted message is
> guaranteed to be presented to the receiving program whole. They
> are commonly used in privilege separated processes, where
> processes with different rights are required to cooperate.
>
> It also mentions socketpair(2) later but does not specify whether
> this would work over tcp(4) connections.
>
> Looking at the libutil imsg code, it doesn't look like there's any
> htonl(3) or byte order swapping when accessing the sizes, so this was
> probably not intended for network use.
>
> So my questions are:
>
> (a) Am I correct in understanding imsg cannot be used to
> communicate over networks in an architecture-independent way?
>
> (b) Should the manual page be updated to reflect this reality,
> so users can better compare possible IPC mechanisms?
>
> (c) Should the library itself be updated to use network byte
> order, so it could be used between different architectures
> over an established TCP connection?
>
> Simplest possible patch for (b) below.
>
> Index: imsg_init.3
> ===================================================================
> RCS file: /cvs/src/lib/libutil/imsg_init.3,v
> retrieving revision 1.21
> diff -u -p -u -r1.21 imsg_init.3
> --- imsg_init.3 16 Feb 2018 07:42:07 -0000 1.21
> +++ imsg_init.3 14 Sep 2018 20:53:10 -0000
> @@ -106,7 +106,7 @@
> .Sh DESCRIPTION
> The
> .Nm imsg
> -functions provide a simple mechanism for communication between processes
> +functions provide a simple mechanism for communication between local
> processes
> using sockets.
> Each transmitted message is guaranteed to be presented to the receiving
> program
> whole.
>
