home *** CD-ROM | disk | FTP | other *** search
/ Source Code 1992 March / Source_Code_CD-ROM_Walnut_Creek_March_1992.iso / usenet / altsrcs / 1 / 1645 < prev    next >
Text File  |  1990-12-28  |  5KB  |  122 lines
  1. Newsgroups: alt.sources
  2. From: auspex!guy@uunet.uu.net (Guy Harris)
  3. Subject: [sun-spots] Device that gives you access to the running kernel file
  4. Message-ID: <1990Aug6.040912.25098@math.lsa.umich.edu>
  5. Date: Mon, 6 Aug 90 04:09:12 GMT
  6.  
  7. Archive-name: dev-vmunix/05-Aug-90
  8. Original-posting-by: auspex!guy@uunet.uu.net (Guy Harris)
  9. Original-subject: Device that gives you access to the running kernel file
  10. Reposted-by: emv@math.lsa.umich.edu (Edward Vielmetti)
  11.  
  12. [Reposted from comp.sys.sun.
  13. Comments on this service to emv@math.lsa.umich.edu (Edward Vielmetti).]
  14.  
  15. The following may be useful, or it may just be an entertaining toy.  It's
  16. a device driver for "/dev/vmunix", an idea I came up with a while ago, to
  17. deal with the problem of programs such as "ps" that need to get at the
  18. kernel file that was booted, to find the kernel's symbol table. 
  19.  
  20. Normally, this isn't a headache, but those of you who have installed new
  21. kernels, calling them something other than "/vmunix", and then tried to
  22. run "ps" or whatever and didn't provide whatever magic argument (if any)
  23. tells it to look elsewhere than "/vmunix", know that it can be a nuisance
  24. on occasion.
  25.  
  26. With this driver, you open "/dev/vmunix", and you have a file descriptor
  27. that lets you read from the kernel file that was booted, even if it's not
  28. named "/vmunix", even if it was renamed since the system was booted (as
  29. long as you open it once before it gets renamed), or even if it was
  30. unlinked since the system was booted - the driver holds onto the vnode, so
  31. it doesn't go away (well, modulo the usual NFSisms; if it's unlinked on
  32. the client, the system should rename it rather than removing it, but if
  33. it's unlinked on the server, you lose).
  34.  
  35. It's quite tiny, only 48 lines of code (counting blank lines and comments
  36. :-)).
  37.  
  38. It has an "open()" routine which, the first time it's called, grabs the
  39. name handed to the boot PROM (and if it's a null string, defaults to
  40. "vmunix"), and opens the file in the current directory with that name. 
  41.  
  42. (This first open must be done in the root directory; the best way to do
  43. this would be with a toy program run from one of the "/etc/rc*" files.
  44. Ideally, this wouldn't be necessary; SunOS does permit a pseudo-device
  45. driver, such as this one, to have an "init" routine, but it appears to be
  46. called quite early in the boot process, before the system is ready to let
  47. you play around with the root file system.)
  48.  
  49. It also has a "read" routine that, if the kernel file was successfully
  50. opened, calls the "read" method for the vnode for that file.
  51.  
  52. You need to modify "sun/conf.c" to have an entry for this device.  You
  53. should be able to just open it and read from it, and get the same data
  54. you'd have gotten had you opened the running kernel file.
  55.  
  56. NOTE: this is, of course, maximally useful *only* if you can coerce all
  57. kmem-groveling programs to use it.  This means whacking on various
  58. commands and "libkvm"; either you need source, or you need to patch the
  59. binaries to look elsewhere than "/vmunix".  I make no claim that this
  60. driver can drop in and make this problem magically vanish....
  61.  
  62. Tested under 4.0.3, on a Sun-3E (well, on an NS5000, but "the difference
  63. that makes no difference is no difference"...).  I was able to do "cp
  64. /dev/vmunix /tmp/vmunix" (from the root directory, so that the first
  65. "open" could find the file), and get the currently-running kernel file.
  66. The test was under UFS; I've not tried it under NFS, nor under 4.1.  No
  67. more rigorous testing has been done.  If you find bugs - or, even better,
  68. find bugs *and* the fixes for same - or have any other comments, send 'em
  69. to me.
  70.  
  71. NOTE: this does not constitute a commitment by Auspex to provide this as
  72. part of SunOS on our systems.
  73.  
  74. #include <sys/errno.h>
  75. #include <sys/param.h>
  76. #include <sys/file.h>
  77. #include <sys/user.h>
  78. #include <sys/uio.h>
  79. #include <sys/time.h>
  80. #include <sys/vnode.h>
  81.  
  82. #include <mon/sunromvec.h>
  83.  
  84. static struct vnode *vmunixvp;
  85.  
  86. /*ARGSUSED*/
  87. int
  88. vmunixopen(dev, flags)
  89.     dev_t dev;
  90.     int flags;
  91. {
  92.     register struct bootparam *bp;
  93.     register char *vmunix_name;
  94.  
  95.     if (vmunixvp == NULL) {
  96.         bp = (*romp->v_bootparam);
  97.         vmunix_name = bp->bp_name;
  98.         if (vmunix_name[0] == '\0') {
  99.             /*
  100.              * No name given when booting; assume it was
  101.              * "vmunix".
  102.              */
  103.             vmunix_name = "vmunix";
  104.         }
  105.         return (vn_open(vmunix_name, UIO_SYSSPACE, FREAD, 0,
  106.             &vmunixvp));
  107.     } else
  108.         return (0);
  109. }
  110.  
  111. /*ARGSUSED*/
  112. int
  113. vmunixread(dev, uio)
  114.     dev_t dev;
  115.     register struct uio *uio;
  116. {
  117.     if (vmunixvp == NULL)
  118.         return (ENOENT);
  119.  
  120.     return (VOP_RDWR(vmunixvp, uio, UIO_READ, 0, u.u_cred));
  121. }
  122.