> A generalized "upcall" mechanism whereby the kernel can get help from
> userland programs would be very nice for a whole pile of problems.

> [U]sing sockets for kernel/userland messages makes a lot of sense.

It does.

During the second half of 2002, I did some work with NetBSD that, among
other things, involved having the kernel make RPC-style calls to
userland.  The interface I chose was that userland, when setting up the
user of this interface, passes in a SOCK_DGRAM socket which is already
connected.  In principle I probably could have just used any SOCK_DGRAM
socket with PR_ATOMIC and PR_RIGHTS set for its so_proto->pr_flags, but
the PR_RIGHTS requirement more or less demanded AF_LOCAL in practice
anyway, and by requiring AF_LOCAL, I could locate the peer socket and
set its buffer sizes automatically, rather than require that userland
do this first.  (I wanted PR_RIGHTS because some of the requests
involved further subsidiary back-and-forthing, and I specifically
wanted to permit a multiple-server userland; requests that involved
further transactions thus had the kernel create a socketpair and pass
one end of it with the request to userland for any interaction beyond a
simple request/reply.  I couldn't think of a better way to arrange for
subsidiary requests to be certain of going to the same userland process
that handled the main request to which they correspond.  Of course, if
what you're doing doesn't require that, you could drop the PR_RIGHTS
aspect, and then maybe you could just require any connected SOCK_DGRAM
(or, maybe, SOCK_STREAM) socket - this would allow all sorts of cool
networked implementations....)

Throughout the work I repeatedly was glad I'd designed that interface
as I had; it proved to be an extremely useful paradigm.  As you note,
it also made failure tolerance relatively easy.

The resulting work's license terms are more liberal than the stock
NetBSD license, so I have no hesitation in offering to send the code to
anyone interested in it, even though I don't see it on a quick glance
at the University's FTP server.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B