4.4BSD/usr/share/man/cat3/kvm_getprocs.0

Compare this file to the similar file:
Show the results in this format:

KVM_GETPROCS(3)             BSD Programmer's Manual            KVM_GETPROCS(3)

NNAAMMEE
     kkvvmm__ggeettpprrooccss, kkvvmm__ggeettaarrggvv, kkvvmm__ggeetteennvvvv - access user process state

SSYYNNOOPPSSIISS
     ##iinncclluuddee <<kkvvmm..hh>>
     ##iinncclluuddee <<ssyyss//kkiinnffoo..hh>>
     ##iinncclluuddee <<ssyyss//kkiinnffoo__pprroocc..hh>>

     _s_t_r_u_c_t _k_i_n_f_o___p_r_o_c _*
     kkvvmm__ggeettpprrooccss(_k_v_m___t _*_k_d, _i_n_t _o_p, _i_n_t _a_r_g, _i_n_t _*_c_n_t);

     _c_h_a_r _*_*
     kkvvmm__ggeettaarrggvv(_k_v_m___t _*_k_d, _c_o_n_s_t _s_t_r_u_c_t _k_i_n_f_o___p_r_o_c _*_p, _i_n_t _n_c_h_r);

     _c_h_a_r _*_*
     kkvvmm__ggeetteennvvvv(_k_v_m___t _*_k_d, _c_o_n_s_t _s_t_r_u_c_t _k_i_n_f_o___p_r_o_c _*_p, _i_n_t _n_c_h_r);

DDEESSCCRRIIPPTTIIOONN
     kkvvmm__ggeettpprrooccss() returns a (sub-)set of active processes in the kernel in-
     dicated by _k_d_. The _o_p and _a_r_g arguments constitute a predicate which lim-
     its the set of processes returned.  The value of _o_p describes the filter-
     ing predicate as follows:

           KKIINNFFOO__PPRROOCC__AALLLL        all processes
           KKIINNFFOO__PPRROOCC__PPIIDD        processes with process id _a_r_g
           KKIINNFFOO__PPRROOCC__PPGGRRPP       processes with process group _a_r_g
           KKIINNFFOO__PPRROOCC__SSEESSSSIIOONN    processes with session _a_r_g
           KKIINNFFOO__PPRROOCC__TTTTYY        processes with tty _a_r_g
           KKIINNFFOO__PPRROOCC__UUIIDD        processes with effective user id _a_r_g
           KKIINNFFOO__PPRROOCC__RRUUIIDD       processes with real user id _a_r_g

     The number of processes found is returned in the reference parameter _c_n_t.
     The processes are returned as a contiguous array of kinfo_proc struc-
     tures.  This memory is locally allocated, and subsequent calls to
     kkvvmm__ggeettpprrooccss() and kkvvmm__cclloossee() will overwrite this storage.

     kkvvmm__ggeettaarrggvv() returns a null-terminated argument vector that corresponds
     to the command line arguments passed to process indicated by _p. Most
     likely, these arguments correspond to the values passed to exec(3) on
     process creation.  This information is, however, deliberately under con-
     trol of the process itself.  Note that the original command name can be
     found, unaltered, in the p_comm field of the process structure returned
     by kkvvmm__ggeettpprrooccss().

     The _n_c_h_r argument indicates the maximum number of characters, including
     null bytes, to use in building the strings.  If this amount is exceeded,
     the string causing the overflow is truncated and the partial result is
     returned.  This is handy for programs like ps(1) and w(1) that print only
     a one line summary of a command and should not copy out large amounts of
     text only to ignore it.  If _n_c_h_r is zero, no limit is imposed and all ar-
     gument strings are returned in their entirety.

     The memory allocated to the argv pointers and string storage is owned by
     the kvm library.  Subsequent kkvvmm__ggeettpprrooccss() and kvm_close(3) calls will
     clobber this storage.

     The kkvvmm__ggeetteennvvvv() function is similar to kkvvmm__ggeettaarrggvv() but returns the
     vector of environment strings.  This data is also alterable by the pro-
     cess.

RREETTUURRNN VVAALLUUEESS
     kkvvmm__ggeettpprrooccss(), kkvvmm__ggeettaarrggvv(), and kkvvmm__ggeetteennvvvv(), all return NULL on
     failure.

BBUUGGSS
     These routines do not belong in the kvm interface.

SSEEEE AALLSSOO
     kvm(3),  kvm_close(3),  kvm_geterr(3),  kvm_nlist(3),  kvm_open(3),
     kvm_openfiles(3),  kvm_read(3),  kvm_write(3)

4.4BSD                           June 4, 1993                                2