kvm_open man page on SmartOS

Man page or keyword search:  
man Server   16655 pages
apropos Keyword Search (all sections)
Output format
SmartOS logo
[printable version]


       kvm_open, kvm_close - specify a kernel to examine

       cc [ flag... ] file... -lkvm [ library...]
       #include <kvm.h>
       #include <fcntl.h>

       kvm_t *kvm_open(char *namelist, char *corefile, char *swapfile, int flag,
	    char *errstr);

       int kvm_close(kvm_t *kd);

       The  kvm_open()	function  initializes  a set of file descriptors to be
       used in subsequent calls to kernel virtual memory ( VM)	routines.   It
       returns	a  pointer  to a kernel identifier that must be used as the kd
       argument in subsequent kernel VM function calls.

       The namelist argument specifies an  unstripped  executable  file	 whose
       symbol  table  will  be	used to locate various offsets in corefile. If
       namelist is NULL, the symbol table of the currently running  kernel  is
       used to determine offsets in the core image.  In this case, it is up to
       the implementation to select an appropriate  way	 to  resolve  symbolic
       references, for instance, using /dev/ksyms as a default namelist file.

       The corefile argument specifies a file that contains an image of physi‐
       cal memory, for instance, a kernel crash dump file  (see	 savecore(1M))
       or the special device /dev/mem. If corefile is NULL, the currently run‐
       ning kernel is accessed, using /dev/mem and /dev/kmem.

       The swapfile argument specifies a file that represents the swap device.
       If  both	 corefile  and	swapfile are NULL, the swap device of the cur‐
       rently running kernel is accessed.  Otherwise,  if  swapfile  is	 NULL,
       kvm_open() may succeed but subsequent kvm_getu(3KVM) function calls may
       fail if the desired information is swapped out.

       The flag function is used to specify read or write access for  corefile
       and may have one of the following values:

		   open for reading

		   open for reading and writing

       The  errstr  argument  is  used to control error reporting.  If it is a
       null pointer, no error messages will be printed. If it is non-null,  it
       is  assumed  to	be the address of a string that will be used to prefix
       error messages generated by kvm_open. Errors are printed to  stderr.  A
       useful value to supply for errstr would be argv[0]. This has the effect
       of printing the process name in front of any error messages.

       Applications using  libkvm are dependent on the underlying  data	 model
       of the kernel image, that is, whether it is a 32−bit or 64−bit kernel.

       The  data  model of these applications must match the data model of the
       kernel in order to correctly interpret the size and offsets  of	kernel
       data  structures.   For	example,  a  32−bit  application that uses the
       32−bit version of the libkvm interfaces will fail to open a 64−bit ker‐
       nel  image.   Similarly, a 64−bit application that uses the 64−bit ver‐
       sion of the libkvm interfaces will fail to open a 32−bit kernel image.

       The kvm_close() function closes all file descriptors that were  associ‐
       ated  with kd. These files are also closed on exit(2) and execve() (see
       exec(2)). kvm_close() also resets  the  proc  pointer  associated  with
       kvm_nextproc(3KVM) and flushes any cached kernel data.

       The  kvm_open() function returns a non-null value suitable for use with
       subsequent kernel VM function calls. On failure, it returns NULL and no
       files are opened.

       The kvm_close() function returns 0 on success and −1 on failure.




       See attributes(5) for descriptions of the following attributes:

       │Interface Stability │ Stable	      │
       │MT-Level	    │ Unsafe	      │

       savecore(1M),	exec(2),    exit(2),	pathconf(2),   getloadavg(3C),
       kstat(3KSTAT),  kvm_getu(3KVM),	kvm_nextproc(3KVM),   kvm_nlist(3KVM),
       kvm_kread(3KVM),	  libkvm(3LIB),sysconf(3C),   proc(4),	attributes(5),

       Kernel core dumps should be examined on the platform on which they were
       created.	 While	a  32-bit  application	running on a 64-bit kernel can
       examine a 32-bit core dump, a 64-bit application running	 on  a	64-bit
       kernel cannot examine a kernel core dump from the 32-bit system.

       On  32-bit  systems, applications that use libkvm to access the running
       kernel must be 32-bit applications. On systems that support both 32-bit
       and 64-bit applications, applications that use the libkvm interfaces to
       access the running kernel must themselves be 64-bit applications.

       Although the libkvm API is Stable, the symbol  names  and  data	values
       that can be accessed through this set of interfaces are Private and are
       subject to ongoing change.

       Applications using  libkvm are likely  to  be  platform-	 and  release-

       Most  of	 the  traditional  uses of libkvm have been superseded by more
       stable interfaces that allow the same information to be extracted  more
       efficiently,  yet  independent of the kernel data model.	 For examples,
       see sysconf(3C),	 proc(4),  kstat(3KSTAT),  getloadavg(3C),  and	 path‐

				  May 2, 2002			KVM_OPEN(3KVM)

List of man pages available for SmartOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net