Subject: Re: Querying an userland program from the kernel
To: None <tech-kern@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 01/25/2004 16:18:02
>>> 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
That's one thing I wanted. But it's not the only thing that was good
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 firstname.lastname@example.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B