>>> A character device, however, you can "chmod 600 /dev/dev0 ; chown
>>> dyoung /dev/dev0".
>> Yes.  Now, if an ioctl on /dev/dev0 takes as (part of?) its argument
>> one of a pair of connected sockets, taking over that socket as the
>> kernel end of the communication, then you have the flexible access
>> control of a device with the interface utility of a socket.
> IIRC, the "interface utility of a socket" that your app needs is
> descriptor-passing.

That's one thing I wanted.  But it's not the only thing that was good
to have.

Like the rest of the benefits using a socket brought, it could also be
done with a special-device interface.  Using a socket, though, involved
writing (and testing and debugging) significantly less code, because
all the socket support code has already been heavily pounded on in the
relevant ways.  I also got multiple instances for free (something that
I think could be addressed in the device paradigm with a cloning
device, at least in -current; the version I was working with didn't
have cloning devices, and even now I don't know enough about them to be
sure they could serve here).

> Do we know yet if Matthias' application needs that?

I don't, at least.

There's certainly nothing wrong with using a special device, if it's a
better fit to the problem (and it may, especially with respect to
permissions).  And I'm certainly not saying that I would be unhappy if
someone chose to use a device instead of a socket.  I'm just offering
my experience that a socket can indeed be a very effective way of
addressing a "kernel makes RPCish call to userland" desire, pointing
out some of the benefits it brought me.

/~\ 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