home *** CD-ROM | disk | FTP | other *** search
/ Nebula 1 / Nebula One.iso / Utilities / Unix / top-v0_3 / Source / INSTALL < prev    next >
Encoding:
Text File  |  1995-03-02  |  7.4 KB  |  175 lines
  1.                              TOP
  2.                      Version 3.3 and later
  3.  
  4.                        William LeFebvre
  5.              and a cast of dozens
  6.  
  7. INSTALLATION
  8.  
  9. Configuration and installation of top is very straightforward.  After
  10. unpacking the sources, run the script "Configure".  It will present you
  11. with a series of questions, all of which should be explained in the
  12. presentation.  After you have answered all the questions, "Configure" will
  13. perform all the necessary configuration.  Once this is finished, type
  14. "make install".  Make will compile the sources then install the resulting
  15. executable and manual page in the appropriate places.
  16.  
  17. The most difficult step in the configuration is the choice of an
  18. appropriate machine-specific module.  The Configure script gives you a
  19. list of choices complete with brief descriptions of when each choice is
  20. appropriate.  Each module is contained in a separate c file in the
  21. directory "machine".  The module contains all of the machine-specific code
  22. that makes top work correctly on the architecture in question.  All of the
  23. code in the top-level directory is machine-independent (or at least
  24. strives to be).  Hints for some module choices that are not obvious are
  25. given at the end of this file.
  26.  
  27. The first comment in each c file in that directory contains the synopsis
  28. AND a detailed description of the machines for which that module is
  29. appropriate.  It also contains a list of authors for that module.  If you
  30. are really stumped in this choice, use grep to find your machine
  31. manufacturer's name or operating system name in machine/*.c.  If you still
  32. can't find one that is appropriate, then chances are very good that one
  33. hasn't been written yet.  If that is the case, then you are out of luck.
  34.  
  35. HANDLING MULTIPLE ARCHITECTURES
  36.  
  37. If you need to recompile top for a different architecture (that is, using
  38. a different module) you need to reconfigure top.  A short cut is available
  39. to make this a little easier.  If all of your previous answers to the
  40. configuration questions (except for the module name of course) are
  41. adequate for the new architecture, then you can just use the command
  42. "Configure <modulename>".  The configuration script will reconfigure top
  43. using the new module and all the answers you gave last time.  It will
  44. finish with a "make clean".  Once that completes, type "make install"
  45. and make will compile the sources and do the installation.
  46.  
  47. HANDLING MULTIPLE OS VERSIONS
  48.  
  49. By far the most frequently received bug report for top is something like
  50. this: "We just upgraded our operating system to version 99.9.9.9 and top
  51. broke.  What should we do?"  The simple answer is "recompile".
  52.  
  53. Top is very sensitive to changes in internal kernel data structures
  54. (especially the proc and user structures).  Some operating systems
  55. (especially SunOS) are notorious for changing these structure in every
  56. minor release of the OS.  This means that a top executable made under one
  57. version of the OS will not always work correctly (if even at all) under
  58. another version.  This is just one of those tough facts of life.  There is
  59. really no way around it.
  60.  
  61. To make life even worse, some operating systems (SunOS again) will use
  62. slightly different proc and user structures on different models.  For
  63. example, "top" built on a SparcStation 2 will not run correctly on a
  64. SparcStation 10, even if they are both running SunOS 4.1.3.  These
  65. unfortunate circumstances make maintaining top very difficult, especially
  66. in an environment that runs several different versions of the same
  67. operating system.
  68.  
  69. But there is hope.  If your operating system has a properly functioning
  70. "uname" command then you can handle this problem rather gracefully.
  71. Included in the distribution is a shell file called "metatop".  All this
  72. shell file does is:
  73.  
  74.     exec top-`uname -m`-`uname -r` "$@"
  75.  
  76. So when you run this script, it execs a filename that is unique to your
  77. specific machine architecture and your OS revision number.
  78.  
  79. To use "metatop", do the following:
  80.  
  81.     . on any machine, run Configure and choose the module that is
  82.       appropriate for the machine
  83.     . for all machines which use the same module:
  84.         . group machines according to machine architecture AND OS
  85.           revision number (i.e.: sun4-4.1.1, sun4c-4.1.1, sun4c-4.1.2,
  86.           sun4-4.1.3, sun4c-4.1.3, sun4m-4.1.3, ...)
  87.         . for each group, choose one machine from that group and on it
  88.           run "make clean; make installmeta".
  89.  
  90.  
  91. The "installmeta" rule in the makefile will insure that top is compiled,
  92. install the shell file "metatop" as "top", then install the executable
  93. "top" with a name appropriate to the machine architecture and OS revision.
  94.  
  95.  
  96. HINTS FOR CHOOSING THE CORRECT MODULE:
  97.  
  98. SUN MULTIPROCESSOR ARCHITECTURES
  99.  
  100. First, we need to be speaking the same language:
  101.  
  102. sun4    a regular sparc sun 4 architecture machine (sparc station 1,
  103.     sparc station 2, IPC, SLC, etc.)
  104.  
  105. sun4m    a multiprocessor sparc (Sparc 10, 4/670, 4/690)
  106.  
  107. I intended to write the sunos4 module so that an executable compiled on a
  108. sun4m machine would work correctly on a sun4 machine.  Unfortunately my
  109. experiments indicate that this cannot be done.  It turns out that the user
  110. structure is so different between these two architectures that nothing
  111. short of a serious hack will make the same executable work correctly on
  112. both machines.  I recommend that you use the separate module "sunos4mp"
  113. when making an executable for a sun4m architecture, and use "sunos4" when
  114. making an executable for sun4 or sun4c architectures.
  115.  
  116. SOLBOURNE OPERATING SYSTEM (OS/MP)
  117.  
  118. If you are running OS/MP version 4.1A, then use the module "osmp4.1a".
  119.  
  120. If you are running a version of OS/MP OLDER than 4.1A (that is, one
  121. of its predecessors), use the module "sunos4".
  122.  
  123. If you are running OS/MP 4.1B or LATER, use the module "sunos4mp".
  124.  
  125. HP/UX OPERATING SYSTEM
  126.  
  127. The module hpux8 works on all version 8 systems.  Some say that it works
  128. with version 9 as well, but one user did send me a separate module for
  129. version 9.  This module has only been tested on series 800 machines.  I
  130. would recommend the following for those running version 9: try hpux9 and
  131. if it doesn't work then try hpux8.  If neither work, then send mail to me
  132. and/or the modules' authors.  Another note:  we have a model 730 supposedly
  133. running version 9.01.  The module hpux9 did not compile successfully, but
  134. the module hpux8 worked fine.
  135.  
  136. NET/2 386BSD SYSTEMS
  137.  
  138. If your version of the operating system has patchkit 2.4 installed,
  139. then you will need to modify machine/m_386bsd.c and uncomment the
  140. definition of PATCHED_KVM.  This patchkit makes what more than a few
  141. people believe to be a wholly unnecessary patch to the way the kvm
  142. routines work.
  143.  
  144. A/UX SYSTEMS
  145.  
  146. There is a module for A/UX 3.1.  Whether or not it works for any other
  147. version is not known.  Proceed at your own risk.
  148.  
  149. Although AUX does not generally have a renice systemcall, it can be
  150. implemented by tweeking kernel memory.  The flag IMPLEMENT_SETPRIORITY
  151. controls the inclusion of this code.  It is off be default.  While
  152. such a simple hack should not be difficult to get right, USE THIS
  153. FEATURE AT YOUR OWN RISK!
  154.  
  155.  
  156. POPULAR SYSTEMS WHICH DO NOT HAVE MODULES
  157.  
  158. AIX SYSTEMS
  159.  
  160. I have had many offers from kind individuals to write an AIX module.
  161. To this date I have not yet received an actual working module.  I 
  162. don't have access to an AIX system, or even if I did I don't have the
  163. time to learn the internals of a completely different OS.
  164.  
  165. SGI IRIX SYSTEMS
  166.  
  167. A few people have offered to write an irix module, but I still have
  168. not received one that works.
  169.  
  170. NeXT SYSTEMS
  171.  
  172. I am working with two separate people in the development of a NeXT
  173. module.
  174.  
  175.