tual memory images, including live systems and crashdumps.  Access to
     live systems is via /dev/mem while crashdumps can be examined via the
     core file generated by savecore(8).  The interface behaves identically in
     both cases.  Memory can be read and written, kernel symbol addresses can
     be looked up efficiently, and information about user processes can be
     gathered.

     kvm_open() is first called to obtain a descriptor for all subsequent
     calls.


COMPATIBILITY

     The kvm interface was first introduced in SunOS.  A considerable number
     of programs have been developed that use this interface, making backward
     compatibility highly desirable.  In most respects, the Sun kvm interface
     is consistent and clean.  Accordingly, the generic portion of the inter-
     face (i.e., kvm_open(), kvm_close(), kvm_read(), kvm_write(), and
     kvm_nlist()) has been incorporated into the BSD interface.  Indeed, many
     kvm applications (i.e., debuggers and statistical monitors) use only this
     subset of the interface.

     The process interface was not kept.  This is not a portability issue
     since any code that manipulates processes is inherently machine depen-
     dent.

     Finally, the Sun kvm error reporting semantics are poorly defined.  The
     library can be configured either to print errors to stderr automatically,
     or to print no error messages at all.  In the latter case, the nature of
     the error cannot be determined.  To overcome this, the BSD interface
     includes a routine, kvm_geterr(3), to return (not print out) the error
     message corresponding to the most recent error condition on the given
     descriptor.


SEE ALSO

     kvm_close(3), kvm_getargv(3), kvm_getenvv(3), kvm_geterr(3),
     kvm_getloadavg(3), kvm_getprocs(3), kvm_nlist(3), kvm_open(3),
     kvm_openfiles(3), kvm_read(3), kvm_write(3)

BSD                              June 4, 1993                              BSD

Man(1) output converted with man2html