home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / next / programm / 5657 < prev    next >
Encoding:
Text File  |  1992-08-16  |  2.9 KB  |  59 lines
  1. Newsgroups: comp.sys.next.programmer
  2. Path: sparky!uunet!munnari.oz.au!metro!mama!greyham
  3. From: greyham@research.canon.oz.au (Graham Stoney)
  4. Subject: Re: Mach messaging to kernel server vs. "traditional" kernel drivers
  5. Message-ID: <Bt3wKx.M2L@research.canon.oz.au>
  6. Sender: news@research.canon.oz.au
  7. Organization: Canon Information Systems Research Australia
  8. References: <1992Aug14.133748.29123@ni.umd.edu>
  9. Date: Mon, 17 Aug 1992 02:36:32 GMT
  10. Lines: 47
  11.  
  12. louie@sayshell.umd.edu (Louis A. Mamakos) writes:
  13. >I'm designing a loadable kernel server which needs to communicate with
  14. >user level processes.  
  15.  
  16. I hope you like a real challenge... I'm also writing a kernel server, and it's
  17. certianly lots of fun and games.
  18.  
  19. Some of the big suprises I found that weren't mentioned in the "Writing
  20. Loadable Kernel Servers" manual were that (at least in 2.1) only the superuser
  21. can send out-of-line messages to a kernel server%, and that the message-based
  22. interface was _40 times_ slower than ioctl#.
  23.  
  24. NeXT's documentation in this area leaves a _great deal_ to be desired; the
  25. manual refers you to Egan & Teixeira for Unix-style drivers - but their book
  26. is about System V, not BSD, and of course doesn't mention NeXT's changes or
  27. anything about Mach. I've had to disassemble parts of the kernel numerous
  28. times; the latest real beauty was disassembling selwakeup() to find that it
  29. takes a thread *, not a proc * like it does in other BSD Unix systems. This
  30. one took a real long time and lots of stabs in the dark to find. Quite
  31. logical once you know about it, but it's documented _nowhere_.
  32.  
  33. And kgdb is next to useless, because you can't depend on the info it gives
  34. you. I used it to single step a simple 'if' condition on an int in an
  35. interrupt routine and it stepped down the _wrong_ path, so I wasted a whole
  36. day until one of the hardware guys here suggested I put a printf on the line
  37. I _knew_ it wasn't getting to. I did so to prove he was wrong and found kgdb
  38. had lied to me. It always prints the values of local variables wrong too;
  39. although it seems to get parameters of a function and info registers right.
  40. We call it the Intel now. NeXT could not possibly have used it without
  41. noticing some ef these problems.
  42.  
  43. Anyone else want to share their experiences?.
  44.  
  45. regards,
  46. Graham
  47.  
  48. %: The kernel server needs access to the kernel task port to vm_write the
  49.    out-of-line data into its (the kernel server's) address space; and the
  50.    only way it can get the kernel task port is if the user process sends it
  51.    in; and the only way the user process can get it is via task_by_unix_pid
  52.    with pid 0; and only the superuser can do that. Fixed in 3.0 though.
  53.  
  54. #: On my NeXTstation color. Your milage may vary.
  55. -- 
  56. Graham Stoney                    | "a Perl script is correct if it's halfway
  57. Flip Dibner fan club, "Hi Flip!" |  readable and gets the job done before your
  58. Ph: +61 2 805-2909  Fax: -2929   |  boss fires you." L. Wall & R. Schwartz
  59.