Subject: Re: direct copy() between two proc address spaces
To: Ian Zagorskih <ianzag@megasignal.com>
From: Matthew Orgass <darkstar@city-net.com>
List: tech-kern
Date: 06/20/2004 16:23:59
On 2004-06-20 ianzag@megasignal.com wrote:
> In short: i'm trying to implement Send/Receive/Reply (SRR) IPC mechanism used
> in QNX4 under NetBSD.
>
> SRR is a very simple [and IMHO powerfull] IPC well described at
> http://qdn.qnx.com/developers/docs/qnx_4.25_docs/qnx4/sysarch/microkernel.html#IPCMESSAGES
>
> Reasons: ATM i have large project originally designed for QNX4 RTOS which
> extensively uses SRR. Project itself includes about 40 separate applications
> which work as a solid system through cooperative communication with each
> other using SRR. Speaking in tech-kern@ it's needless to say that i need to
> port this system on NetBSD :)
>
> In general, QNX4 SRR IPC can be implemented completely inside userland using
> existing IPC mechanisms i.e. on top of shm/sem, sockets, maybe message queue
> etc. On the other hand, some tests i made ATM leads to the conclusion that
> implementing this IPC scheme inside the kernel is much more simplier. Note
> that client and server processes aren't required to be in any child/parent
> relations with each other. It means that i cannot relay on passing unnamed
> shared resources between them like file descriptors, shared memory or
> semaphores.

  Looking at the link you provided, Send/Receive/Reply is a varient of the
socket interface that uses pids as identifiers, provides space for the
reply in the send call (reducing the number of system calls needed for the
typical transaction and allowing some performance hacks), and blocks the
sender until the reply is received.

  I can't see why implementing this in the kernel should be simpler than a
userland version based on local sockets (note that SysV IPC has a separate
namespace and could potentially be used too).  IMO, the only reason this
should be done in the kernel is for performance, if necessary.  I think
page loan is implemented for local sockets, which should give you good
performance for large data movement unless the receive buffer is is the
same as the send buffer.  A general sendrecv system call might make sense,
but I don't think a direct kernel implementation of send/receive/reply is
a good idea outside a compatability environment.

Matthew Orgass
darkstar@city-net.com