🚀 go-pugleaf

I'm designing a loadable kernel server which needs to communicate with
user level processes.  

In the past, the kernel driver I did has used a character special
device to do this, and the tradional open/close/read/write/ioctl/etc
interface via the cdevsw[] table.  This works and all is well.

I'm doing a different driver which needs similar functions, but am
considering using Mach messaging rather than a character special
device to do what I want.  Now, one thing which I'm trying to
determine how to implement with the Mach messaging design is how to do
access control and credentials checking.  With the tradional UNIX
device driver, I can use suser() to protect access to certain
protected functions.  How can I determine the identity, in some useful
sense, of the sender in the Mach messaging case?

The more that I think about this, the less that I'm likely to use the
Mach messaging design for two reasons:

	* I can forget about porting the kernel driver to any other
	platform; thougth the NeXT's kernel network API has already
	hosed me to a big extent here.

	* It doesn't seem like it will buy me anything.  I was excited
	at the prospect of using out-of-line data to move moderately size
	hunks of data between the kernel driver and user code using
	the fancy Mach copy-on-write VM.  But it seems that since the
	loadable kernel servers don't allow this to work, and I have to
	copy the data anyway.

louie