home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / next / programm / 5605 < prev    next >
Encoding:
Text File  |  1992-08-14  |  1.8 KB  |  44 lines
  1. Newsgroups: comp.sys.next.programmer
  2. Path: sparky!uunet!haven.umd.edu!ni.umd.edu!sayshell.umd.edu!louie
  3. From: louie@sayshell.umd.edu (Louis A. Mamakos)
  4. Subject: Mach messaging to kernel server vs. "traditional" kernel drivers
  5. Message-ID: <1992Aug14.133748.29123@ni.umd.edu>
  6. Sender: usenet@ni.umd.edu (USENET News System)
  7. Nntp-Posting-Host: sayshell.umd.edu
  8. Organization: University of Maryland, College Park
  9. Date: Fri, 14 Aug 1992 13:37:48 GMT
  10. Lines: 32
  11.  
  12.  
  13. I'm designing a loadable kernel server which needs to communicate with
  14. user level processes.  
  15.  
  16. In the past, the kernel driver I did has used a character special
  17. device to do this, and the tradional open/close/read/write/ioctl/etc
  18. interface via the cdevsw[] table.  This works and all is well.
  19.  
  20. I'm doing a different driver which needs similar functions, but am
  21. considering using Mach messaging rather than a character special
  22. device to do what I want.  Now, one thing which I'm trying to
  23. determine how to implement with the Mach messaging design is how to do
  24. access control and credentials checking.  With the tradional UNIX
  25. device driver, I can use suser() to protect access to certain
  26. protected functions.  How can I determine the identity, in some useful
  27. sense, of the sender in the Mach messaging case?
  28.  
  29. The more that I think about this, the less that I'm likely to use the
  30. Mach messaging design for two reasons:
  31.  
  32.     * I can forget about porting the kernel driver to any other
  33.     platform; thougth the NeXT's kernel network API has already
  34.     hosed me to a big extent here.
  35.  
  36.     * It doesn't seem like it will buy me anything.  I was excited
  37.     at the prospect of using out-of-line data to move moderately size
  38.     hunks of data between the kernel driver and user code using
  39.     the fancy Mach copy-on-write VM.  But it seems that since the
  40.     loadable kernel servers don't allow this to work, and I have to
  41.     copy the data anyway.
  42.  
  43. louie
  44.