home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / unix / internal / 2157 < prev    next >
Encoding:
Internet Message Format  |  1993-01-24  |  2.0 KB
  1. Xref: sparky comp.unix.internals:2157 comp.unix.wizards:5625
  2. Newsgroups: comp.unix.internals,comp.unix.wizards
  3. Path: sparky!uunet!hobbes!md
  4. From: md@sco.COM (Michael Davidson)
  5. Subject: Re: reading a processes u-area
  6. Organization: The Santa Cruz Operation, Inc.
  7. Date: Sat, 23 Jan 1993 18:20:08 GMT
  8. Message-ID: <1993Jan23.182008.29935@sco.com>
  9. References: <1993Jan23.161039.10412@unilabs.uucp>
  10. Sender: news@sco.com (News admin)
  11. Lines: 32
  12.  
  13.  
  14. chare@unilabs.uucp (Chris Hare) writes:
  15.  
  16. >In an attempt to understand more about how the kernel operates, I am trying
  17. >to write a version of crash.  As a result, I will in several different
  18. >instances need access to a processes u-block.  I would prefer to try and do
  19. >this without having to make use of system-specific system calls, although
  20. >if this is going to be the only method, then I guess I will have to resort
  21. >to it.
  22.  
  23. The precise mechanism by which you get access to the u-block for a
  24. process is inevitably going to be *very* system specific regardless
  25. of whether you use a system call if one happens to be available
  26. (eg the RDUBLK subfunction of sysi86() on Intel SVr3 and SVr4 systems)
  27. or if you just go poking around in /dev/kmem and /dev/swap.
  28.  
  29. To be honest a lot of the stuff that "crash" does is inherently
  30. very system specific since it has knowledge of internal kernel
  31. data structures that may be implemented differently (if, indeed, they
  32. exist at all) on different systems.
  33.  
  34. One of the secrets of writing portable code is to recognise which
  35. parts of the code are inherently non-portable and implement those
  36. functions in a separate module with a clean interface do that they
  37. can be re-implemented easily when you have to port to another system.
  38. Just put the function for accessing the u-block in a separate module,
  39. implement it with whatever support is available on your system and
  40. quit worrying about it ....
  41.  
  42. (Unfortunately, even if you *do* port this code to another system
  43. I hope you realise that there is a good chance that the u-block you
  44. get back won't look much like the one on the first system ....)
  45.