TOPIC   #  NAME           DESCRIPTION
-----  --- ------------   ------------------------------------------------
  51 acct          - switch process accounting on or off
 184 capget        - get process capabilities
 185 capset        - set process capabilities
 120 clone         - create a child process
  11 execve        - execute program
   1 exit          - terminate the current process
   2 fork          - create a child process 
  96 getpriority   - get program scheduling priority
 112 idle          - make process 0 idle
 128 init_module   - initialize a loadable module entry
 117 ipc           - System V IPC system calls
 142 newselect     - sync I/O multiplexing
  34 nice          - change process priority
 136 personality   - set the process execution domain
 172 prctl         - operations on a process
  26 ptrace        - process trace
  97 setpriority   - set program scheduling priority
 190 vfork         - create a child process and block parent
 111 vhangup       - virtually hangup the current tty


----------------------------------------------------------------------------
  51 acct          - switch process accounting on or off
----------------------------------------------------------------------------
  mov   eax,51
  mov   ebx,filename_ptr
  int   80h

       When  called  with the name of an existing file as argument, accounting
       is turned on, records for each  terminating  process  are  appended  to
       filename as it terminates.  An argument of NULL causes accounting to be
       turned off.

RETURN VALUE
       On success, zero is returned.  On error, -1 is returned, and  errno  is
       set appropriately.

ERRORS
       EACCES Write permission is denied for the specified file.

       EACCES The argument filename is not a regular file.

       EFAULT filename points outside your accessible address space.

       EIO    Error writing to the file filename.

       EISDIR filename is a directory.

       ELOOP  Too  many symbolic links were encountered in resolving filename.

       ENAMETOOLONG
              filename was too long.

       ENOENT The specified filename does not exist.

       ENOMEM Out of memory.

       ENOSYS BSD process accounting has not been enabled when  the  operating
              system  kernel was compiled.  The kernel configuration parameter
              controlling this feature is CONFIG_BSD_PROCESS_ACCT.

       ENOTDIR
              A component used as a directory in filename is  not  in  fact  a
              directory.

       EPERM  The calling process has no permission to enable process account-
              ing.

       EROFS  filename refers to a file on a read-only file system.

       EUSERS There are no more free file structures or we ran out of  memory.

NOTES
       No accounting is produced for programs running when a crash occurs.  In
       particular, nonterminating processes are never accounted for.



----------------------------------------------------------------------------
 184 capget        - get process capabilities
----------------------------------------------------------------------------
   mov  eax,184
   mov  ebx,header
   mov  ecx,data
   int  80h

       As of Linux 2.2, the power of the superuser (root) has been partitioned
       into a set of discrete capabilities.  Every process has a set of effec-
       tive  capabilities  identifying which capabilities (if any) it may cur-
       rently exercise.  Every process also has a set of inheritable capabili-
       ties  that  may  be  passed through an execve(2) and a set of permitted
       capabilites that it can make effective or inheritable.

       This function is the raw kernel interface for getting
       capabilities.  Not only are these system calls specific to Linux,
       but the kernel API is likely to change and use of these  functions  (in
       particular  the  format of the cap_user_*_t types) is subject to change
       with each kernel revision.

       The portable interfaces are  cap_set_proc(3)  and  cap_get_proc(3);  if
       possible  you should use those interfaces in applications.  If you wish
       to use the Linux extensions in applications, you should use the easier-
       to-use interfaces capsetp(3) and capgetp(3).

RETURN VALUE
       On  success,  zero is returned.  On error, -1 is returned, and errno is
       set appropriately.

ERRORS
       EINVAL One of the arguments was invalid.

       EPERM  An attempt was made to add a capability to the Permitted set, or
              to set a capability in the Effective or Inheritable sets that is
              not in the Permitted set.

FURTHER INFORMATION
       The portable interface to the capability querying and setting functions
       is provided by the libcap library and is available from here:
       ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs

SEE ALSO
       capabilities(7)


----------------------------------------------------------------------------
 185 capset        - set process capabilities
----------------------------------------------------------------------------
  mov   eax,185
  mov   ebx,header
  mov   ecx,data


       As of Linux 2.2, the power of the superuser (root) has been partitioned
       into a set of discrete capabilities.  Every process has a set of effec-
       tive  capabilities  identifying which capabilities (if any) it may cur-
       rently exercise.  Every process also has a set of inheritable capabili-
       ties  that  may  be  passed through an execve(2) and a set of permitted
       capabilites that it can make effective or inheritable.

       This function is the raw kernel interface for settng
       capabilities.  Not only are these system calls specific to Linux,
       but the kernel API is likely to change and use of these  functions  (in
       particular  the  format of the cap_user_*_t types) is subject to change
       with each kernel revision.

       The portable interfaces are  cap_set_proc(3)  and  cap_get_proc(3);  if
       possible  you should use those interfaces in applications.  If you wish
       to use the Linux extensions in applications, you should use the easier-
       to-use interfaces capsetp(3) and capgetp(3).

RETURN VALUE
       On  success,  zero is returned.  On error, -1 is returned, and errno is
       set appropriately.

ERRORS
       EINVAL One of the arguments was invalid.

       EPERM  An attempt was made to add a capability to the Permitted set, or
              to set a capability in the Effective or Inheritable sets that is
              not in the Permitted set.

FURTHER INFORMATION
       The portable interface to the capability querying and setting functions
       is provided by the libcap library and is available from here:
       ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs

SEE ALSO
       capabilities(7)


----------------------------------------------------------------------------
 120 clone         - create a child process
----------------------------------------------------------------------------
   mov  eax,120
   mov  ebx,flags
   mov  ecx,child_stack
   int  80h

  comments from HLA library wrapper for clone

  // This one can't be a trivial wrapper function because
  // creating a new thread also creates a new stack for the
  // child thread. Therefore, things like return addresses
  // and parameters only belong to the parent thread. Since
  // this procedure gets called by the parent, we have to
  // pull some tricks to make sure we can still return to
  // the caller from both the parent and the child thread.
  //
  // sysclone- Simple wrapper that simulates the standard
  // Linux int( $80 ) invocation.
  push ebx
  push ecx
  // Okay, we've got to copy the EBX, ECX, and
  // return address values to the child's stack.
  // Note that the stack looks like this:
  //
  // Parent:
  //
  // child_stack+16
  // flags +12
  // return +8
  // ebx +4
  // ecx +0 (esp)
  //
  mov  eax,[esp+16] ;// Get ptr to child's stack.
  sub  eax.20       ; // Make it look like parent's.
  mov  [eax+4],ebx  ;// Simulate the pushes
  mov  [eax],ecx    ;
  mov  ebx,[esp+8]  ;// Copy the return address.
  mov  [eax+8], ebx ;
  mov  ecx,eax      ;// sys_clone expects ESP in ECX.
  mov  ebx,[esp+12] ;// Get flags parameter into EBX.
  mov  eax.linux.sys_clone
  int  80h;
  pop  ecx  ; // Cleans up the stack for
  pop  ebx  ; // both parent and child after
  ret  8  ; // all the work above.

       Unlike fork(2), this call allow the child process to share  parts  of
       its  execution  context  with  the  calling process, such as the memory
       space, the table of file descriptors, and the table of signal handlers.
       (Note  that on this manual page, "calling process" normally corresponds
       to "parent process".  But see the description of CLONE_PARENT below.)

       The main use of clone is to implement threads: multiple threads of con-
       trol in a program that run concurrently in a shared memory space.

       The sysclone system call corresponds more closely to fork(2) in that
       execution in the child continues from the point of the call. Thus,
       sysclone only requires the flags and child_stack arguments, which have
       the same meaning as for clone. (Note that the order of these arguments
       differs from clone.)

       Another difference for sysclone is that the child_stack argument may be
       zero, in which case copy-on-write semantics ensure that the child gets
       separate copies of stack pages when either process modifies the stack.
       In this case, for correct operation, the clone_vm option should not be
       specified.
 
       When the fn(arg) function application returns, the child process termi-
       nates.   The  integer  returned  by  fn  is the exit code for the child
       process.  The child process may also terminate  explicitly  by  calling
       exit(2) or after receiving a fatal signal.

       The  child_stack  argument  specifies the location of the stack used by
       the child process.  Since the child and calling process may share  mem-
       ory,  it  is  not possible for the child process to execute in the same
       stack as the calling process.  The calling process must  therefore  set
       up memory space for the child stack and pass a pointer to this space to
       clone.  Stacks grow downwards on all processors that run Linux  (except
       the  HP  PA  processors),  so child_stack usually points to the topmost
       address of the memory space set up for the child stack.

       The low byte of flags contains the number of the  signal  sent  to  the
       parent  when  the  child dies.  If this signal is specified as anything
       other than SIGCHLD, then the parent process must specify the __WALL  or
       __WCLONE options when waiting for the child with wait(2).  If no signal
       is specified, then the parent process is not signaled  when  the  child
       terminates.

       flags  may  also  be bitwise-or'ed with one or several of the following
       constants, in order to specify  what  is  shared  between  the  calling
       process and the child process:


       CLONE_PARENT
              (Linux  2.4  onwards) If CLONE_PARENT is set, then the parent of
              the new child (as returned by getppid(2)) will be  the  same  as
              that of the calling process.

              If  CLONE_PARENT  is not set, then (as with fork(2)) the child's
              parent is the calling process.

              Note that it is the parent process, as returned  by  getppid(2),
              which  is  signaled  when  the  child  terminates,  so  that  if
              CLONE_PARENT is set, then the parent  of  the  calling  process,
              rather than the calling process itself, will be signaled.


       CLONE_FS
              If CLONE_FS is set, the caller and the child processes share the
              same file system information.  This includes  the  root  of  the
              file  system, the current working directory, and the umask.  Any
              call to chroot(2), chdir(2), or umask(2) performed by the  call-
              ing  process or the child process also takes effect in the other
              process.

              If CLONE_FS is not set, the child process works on a copy of the
              file  system  information  of the calling process at the time of
              the clone call.  Calls to  chroot(2),  chdir(2),  umask(2)  per-
              formed  later  by  one  of the processes do not affect the other
              process.


       CLONE_FILES
              If CLONE_FILES is set, the calling process and  the  child  pro-
              cesses  share  the same file descriptor table.  File descriptors
              always refer to the same files in the calling process and in the
              child  process.   Any  file  descriptor  created  by the calling
              process or by the child process  is  also  valid  in  the  other
              process.   Similarly,  if  one  of  the  processes closes a file
              descriptor, or changes its associated flags, the  other  process
              is also affected.

              If  CLONE_FILES is not set, the child process inherits a copy of
              all file descriptors opened in the calling process at  the  time
              of  clone.   Operations  on  file descriptors performed later by
              either the calling process or the child process  do  not  affect
              the other process.


       CLONE_NEWNS
              (Linux 2.4.19 onwards) Start the child in a new namespace.

              Every  process  lives in a namespace. The namespace of a process
              is the data (the set of mounts) describing the file hierarchy as
              seen  by  that  process.  After  a fork(2) or clone(2) where the
              CLONE_NEWNS flag is not set, the child lives in the same  names-
              pace  as  the  parent.   The system calls mount(2) and umount(2)
              change the namespace of the calling process,  and  hence  affect
              all processes that live in the same namespace, but do not affect
              processes in a different namespace.

              After a clone(2) where the CLONE_NEWNS flag is set,  the  cloned
              child  is started in a new namespace, initialized with a copy of
              the namespace of the parent.

              Only a privileged process may specify the CLONE_NEWNS flag.   It
              is not permitted to specify both CLONE_NEWNS and CLONE_FS in the
              same clone call.


       CLONE_SIGHAND
              If CLONE_SIGHAND is set, the calling process and the child  pro-
              cesses  share the same table of signal handlers.  If the calling
              process or child process calls sigaction(2) to change the behav-
              ior  associated  with  a  signal, the behavior is changed in the
              other process as well.  However, the calling process  and  child
              processes  still  have distinct signal masks and sets of pending
              signals.  So, one of them may  block  or  unblock  some  signals
              using sigprocmask(2) without affecting the other process.

              If  CLONE_SIGHAND  is not set, the child process inherits a copy
              of the signal handlers of the calling process at the time  clone
              is  called.  Calls to sigaction(2) performed later by one of the
              processes have no effect on the other process.


       CLONE_PTRACE
              If CLONE_PTRACE is specified, and the calling process  is  being
              traced, then trace the child also (see ptrace(2)).


       CLONE_VFORK
              If  CLONE_VFORK  is set, the execution of the calling process is
              suspended until the child releases its virtual memory  resources
              via a call to execve(2) or _exit(2) (as with vfork(2)).

              If  CLONE_VFORK is not set then both the calling process and the
              child are schedulable after the call, and an application  should
              not rely on execution occurring in any particular order.


       CLONE_VM
              If  CLONE_VM is set, the calling process and the child processes
              run in the same memory space.  In particular, memory writes per-
              formed  by  the calling process or by the child process are also
              visible in the other process.  Moreover, any memory  mapping  or
              unmapping  performed  with  mmap(2) or munmap(2) by the child or
              calling process also affects the other process.

              If CLONE_VM is not set, the child process  runs  in  a  separate
              copy  of  the memory space of the calling process at the time of
              clone.  Memory writes or file mappings/unmappings  performed  by
              one of the processes do not affect the other, as with fork(2).


       CLONE_PID
              (Obsolete)  If  CLONE_PID  is  set, the child process is created
              with the same process ID as the calling process.  This  is  good
              for  hacking  the  system,  but otherwise of not much use. Since
              2.3.21 this flag can  be  specified  only  by  the  system  boot
              process (PID 0).  It disappeared in Linux 2.5.16.


       CLONE_THREAD
              (Linux  2.4 onwards) If CLONE_THREAD is set, the child is placed
              in the same thread group as the calling process.

              If CLONE_THREAD is not set, then the child is placed in its  own
              (new) thread group, whose ID is the same as the process ID.

              (Thread  groups  are  feature  added in Linux 2.4 to support the
              POSIX threads notion of a set of threads sharing a  single  PID.
              In  Linux  2.4, calls to getpid(2) return the thread group ID of
              the caller.)


RETURN VALUE
       On success, the PID of the child process is returned  in  the  caller's
       thread of execution.  On failure, a -1 will be returned in the caller's
       context, no child process will be created, and errno will be set appro-
       priately.


ERRORS
       EAGAIN Too many processes are already running.

       ENOMEM Cannot  allocate  sufficient memory to allocate a task structure
              for the child, or to copy those parts of  the  caller's  context
              that need to be copied.

       EINVAL Returned   by   clone   when  a  zero  value  is  specified  for
              child_stack.

       EINVAL Both CLONE_FS and CLONE_NEWNS were specified in flags.

       EINVAL CLONE_THREAD was specified, but CLONE_SIGHAND  was  not.  (Since
              Linux 2.5.35.)

       EINVAL Precisely  one of CLONE_DETACHED and CLONE_THREAD was specified.
              (Since Linux 2.6.0-test6.)

       EINVAL CLONE_SIGHAND was specified, but CLONE_VM was not. (Since  Linux
              2.6.0-test6.)

       EPERM  CLONE_NEWNS was specified by a non-root process (process without
              CAP_SYS_ADMIN).

       EPERM  CLONE_PID was specified by a process other than process 0.


BUGS
       There is no entry for clone in libc version 5.  libc 6 (a.k.a. glibc 2)
       provides clone as described in this manual page.


SEE ALSO
       fork(2), wait(2), pthread_create(3)


----------------------------------------------------------------------------
  11 execve        - execute program
----------------------------------------------------------------------------
  mov  eax,011
  mov  ebx,filename
  mov   ecx,argv
  mov   edx,envp
  int   80h


       execve() executes the program pointed to by filename.  filename must be
       either  a  binary  executable,  or a script starting with a line of the
       form "#! interpreter [arg]".  In the latter case, the interpreter  must
       be  a  valid  pathname  for an executable which is not itself a script,
       which will be invoked as interpreter [arg] filename.

       argv is an array of argument strings passed to the new  program.   envp
       is an array of strings, conventionally of the form key=value, which are
       passed as environment to the new program.  Both argv and envp  must  be
       terminated  by a null pointer.  The argument vector and environment can
       be accessed by the called program's main function, when it  is  defined
       as int main(int argc, char *argv[], char *envp[]).

       execve() does not return on success, and the text, data, bss, and stack
       of the calling process are overwritten by that of the  program  loaded.
       The  program  invoked  inherits the calling process's PID, and any open
       file descriptors that are not set to close on exec.  Signals pending on
       the  calling  process are cleared.  Any signals set to be caught by the
       calling process are reset to their default behaviour.  The SIGCHLD sig-
       nal (when set to SIG_IGN) may or may not be reset to SIG_DFL.

       If  the current program is being ptraced, a SIGTRAP is sent to it after
       a successful execve().

       If the set-uid bit is set on the program file pointed  to  by  filename
       the  effective user ID of the calling process is changed to that of the
       owner of the program file.  Similarly, when the set-gid bit of the pro-
       gram  file  is set the effective group ID of the calling process is set
       to the group of the program file.

       If the executable is an a.out dynamically-linked binary executable con-
       taining  shared-library  stubs,  the  Linux  dynamic linker ld.so(8) is
       called at the start of execution to bring needed shared libraries  into
       core and link the executable with them.

       If  the  executable  is a dynamically-linked ELF executable, the inter-
       preter named in the PT_INTERP segment is used to load the needed shared
       libraries.   This interpreter is typically /lib/ld-linux.so.1 for bina-
       ries linked with the Linux libc version 5,  or  /lib/ld-linux.so.2  for
       binaries linked with the GNU libc version 2.

RETURN VALUE
       On  success,  execve()  does  not  return, on error -1 is returned, and
       errno is set appropriately.

ERRORS
       EACCES The file or a script interpreter is not a regular file.

       EACCES Execute permission is denied for the file or  a  script  or  ELF
              interpreter.

       EACCES The file system is mounted noexec.

       EPERM  The  file  system  is  mounted nosuid, the user is not the supe-
              ruser, and the file has an SUID or SGID bit set.

       EPERM  The process is being traced, the user is not the  superuser  and
              the file has an SUID or SGID bit set.

       E2BIG  The argument list is too big.

       ENOEXEC
              An  executable  is  not in a recognised format, is for the wrong
              architecture, or has some other format error that means it  can-
              not be executed.

       EFAULT filename points outside your accessible address space.

       ENAMETOOLONG
              filename is too long.

       ENOENT The file filename or a script or ELF interpreter does not exist,
              or a shared library needed for file  or  interpreter  cannot  be
              found.

       ENOMEM Insufficient kernel memory was available.

       ENOTDIR
              A  component  of  the path prefix of filename or a script or ELF
              interpreter is not a directory.

       EACCES Search permission is denied on a component of the path prefix of
              filename or the name of a script interpreter.

       ELOOP  Too  many  symbolic links were encountered in resolving filename
              or the name of a script or ELF interpreter.

       ETXTBSY
              Executable was open for writing by one or more processes.

       EIO    An I/O error occurred.

       ENFILE The limit on the total number of files open on  the  system  has
              been reached.

       EMFILE The process has the maximum number of files open.

       EINVAL An  ELF  executable  had  more than one PT_INTERP segment (i.e.,
              tried to name more than one interpreter).

       EISDIR An ELF interpreter was a directory.

       ELIBBAD
              An ELF interpreter was not in a recognised format.


NOTES
       SUID and SGID processes can not be ptrace()d.

       Linux ignores the SUID and SGID bits on scripts.

       The result of mounting a filesystem nosuid vary  between  Linux  kernel
       versions: some will refuse execution of SUID/SGID executables when this
       would give the user powers she did not have already (and return EPERM),
       some will just ignore the SUID/SGID bits and exec successfully.

       A  maximum  line length of 127 characters is allowed for the first line
       in a #! executable shell script.


SEE ALSO
       chmod(2), fork(2), execl(3), environ(5), ld.so(8)

----------------------------------------------------------------------------
   1 exit          - terminate the current process
----------------------------------------------------------------------------
  mov  eax,001
  mov  ebx,return_value
  int  80h

       The  function  _exit  terminates the calling process "immediately". Any
       open file descriptors belonging to the process are closed; any children
       of the process are inherited by process 1, init, and the process's par-
       ent is sent a SIGCHLD signal.

       The value status is returned to the parent  process  as  the  process's
       exit  status,  and  can  be  collected  using one of the wait family of
       calls.

       The function _Exit is equivalent to _exit.

RETURN VALUE
       These functions do not return.

NOTES
       For  a  discussion  on the effects of an exit, the transmission of exit
       status, zombie processes, signals sent, etc., see exit(3).

       The function _exit is like exit(), but does not call any functions reg-
       istered with the ANSI C atexit function, nor any registered signal han-
       dlers. Whether it flushes standard I/O buffers  and  removes  temporary
       files  created  with  tmpfile(3)  is  implementation-dependent.  On the
       other hand, _exit does close open file descriptors, and this may  cause
       an unknown delay, waiting for pending output to finish. If the delay is
       undesired, it may be useful to call  functions  like  tcflush()  before
       calling _exit().  Whether any pending I/O is cancelled, and which pend-
       ing I/O may be cancelled upon _exit(), is implementation-dependent.

SEE ALSO
       fork(2), execve(2), waitpid(2), wait4(2),  kill(2),  wait(2),  exit(3),
       termios(3)

----------------------------------------------------------------------------
   2 fork          - create a child process 
----------------------------------------------------------------------------
  mov  eax,002
  int  80h              ;returns 0 to child,  childs PID to parent

       fork  creates a child process that differs from the parent process only
       in its PID and PPID, and in the fact that resource utilizations are set
       to 0.  File locks and pending signals are not inherited.

       Under Linux, fork is implemented using copy-on-write pages, so the only
       penalty incurred by fork is the time and memory required  to  duplicate
       the parent's page tables, and to create a unique task structure for the
       child.

RETURN VALUE
       On success, the PID of the child process is returned  in  the  parent's
       thread  of execution, and a 0 is returned in the child's thread of exe-
       cution.  On failure, a -1 will be returned in the parent's context,  no
       child process will be created, and errno will be set appropriately.

ERRORS
       EAGAIN fork cannot allocate sufficient memory to copy the parent's page
              tables and allocate a task structure for the child.

       ENOMEM fork failed to allocate the necessary kernel structures  because
              memory is tight.

SEE ALSO
       clone(2), execve(2), vfork(2), wait(2)


----------------------------------------------------------------------------
  96 getpriority   - get program scheduling priority
----------------------------------------------------------------------------
  mov  eax,096
  mov  ebx,which
  mov  ecx,who
  int  80h

       The  scheduling  priority  of  the  process, process group, or user, as
       indicated by which and who is obtained with the  getpriority  call  and
       set   with  the  setpriority  call.   Which  is  one  of  PRIO_PROCESS,
       PRIO_PGRP, or PRIO_USER, and who is interpreted relative  to  which  (a
       process  identifier  for  PRIO_PROCESS,  process  group  identifier for
       PRIO_PGRP, and a user ID for PRIO_USER).  A zero value for who  denotes
       (respectively)  the  calling  process, the process group of the calling
       process, or the real user ID of the calling process.  Prio is  a  value
       in the range -20 to 20 (but see the Notes below).  The default priority
       is 0; lower priorities cause more favorable scheduling.

       The getpriority call returns the  highest  priority  (lowest  numerical
       value) enjoyed by any of the specified processes.  The setpriority call
       sets the priorities of all of the specified processes to the  specified
       value.  Only the super-user may lower priorities.

RETURN VALUE
       Since getpriority can legitimately return the value -1, it is necessary
       to clear the external variable errno prior to the call, then  check  it
       afterwards to determine if a -1 is an error or a legitimate value.  The
       setpriority call returns 0 if there is no error, or -1 if there is.

ERRORS
       ESRCH  No process was located using the which and who values specified.

       EINVAL Which was not one of PRIO_PROCESS, PRIO_PGRP, or PRIO_USER.

       In addition to the errors indicated above, setpriority may fail if:

       EPERM  A  process  was  located, but neither the effective nor the real
              user ID of the caller matches its effective user ID.

       EACCES A non super-user attempted to lower a process priority.

SEE ALSO
       nice(1), fork(2), renice(8)


----------------------------------------------------------------------------
 112 idle          - make process 0 idle
----------------------------------------------------------------------------
  mov  eax,112
  int  80h

       idle  is  an  internal system call used during bootstrap.  It marks the
       process's pages as swappable, lowers its priority, and enters the  main
       scheduling loop.  idle never returns.

       Only  process  0  may call idle.  Any user process, even a process with
       super-user permission, will receive EPERM.

RETURN VALUE
       idle never returns for process 0, and always  returns  -1  for  a  user
       process.

ERRORS
       EPERM  Always, for a user process.

CONFORMING TO
       This  function  is  Linux-specific,  and should not be used in programs
       intended to be portable.

NOTES
       Since 2.3.13 this system call does not exist anymore.


----------------------------------------------------------------------------
 128 init_module   - initialize a loadable module entry
----------------------------------------------------------------------------
  mov  eax,128
  mov  ebx,theName
  mov  ecx,image
  int  80h

       init_module loads the relocated module image into kernel space and runs
       the module's init function.

       The module image begins with a module structure and is followed by code
       and data as appropriate.  The module structure is defined as follows:

              struct module
              {
                unsigned long size_of_struct;
                struct module *next;
                const char *name;
                unsigned long size;
                long usecount;
                unsigned long flags;
                unsigned int nsyms;
                unsigned int ndeps;
                struct module_symbol *syms;
                struct module_ref *deps;
                struct module_ref *refs;
                int (*init)(void);
                void (*cleanup)(void);
                const struct exception_table_entry *ex_table_start;
                const struct exception_table_entry *ex_table_end;
              #ifdef __alpha__
                unsigned long gp;
              #endif
              };

       All  of  the  pointer  fields, with the exception of next and refs, are
       expected to point within the module body and be initialized  as  appro-
       priate for kernel space, i.e. relocated with the rest of the module.

       This system call is only open to the superuser.

RETURN VALUE
       On  success,  zero  is returned.  On error, -1 is returned and errno is
       set appropriately.

ERRORS
       EPERM  The user is not the superuser.

       ENOENT No module by that name exists.

       EINVAL Some image slot filled in incorrectly, image->name does not cor-
              respond to the original module name, some image->deps entry does
              not correspond to a loaded module, or some other similar  incon-
              sistency.

       EBUSY  The module's initialization routine failed.

       EFAULT name or image is outside the program's accessible address space.

SEE ALSO
       create_module(2), delete_module(2), query_module(2).


----------------------------------------------------------------------------
 117 ipc           - System V IPC system calls
----------------------------------------------------------------------------
  parms:
  theCall dd
  first   dd
  second  dd
  third   dd
  forth   dd
  fifth   dd

  lea  parms,ebx
  int  80h

       socketcall  is a common kernel entry point for the socket system calls.
       call determines which socket function to  invoke.   args  points  to  a
       block  containing the actual arguments, which are passed through to the
       appropriate call.

       User programs should call the  appropriate  functions  by  their  usual
       names.   Only  standard library implementors and kernel hackers need to
       know about socketcall.

CONFORMING TO
       This call is specific to Linux, and should  not  be  used  in  programs
       intended to be portable.

SEE ALSO
       accept(2),  bind(2),  connect(2),  getpeername(2), getsockname(2), get-
       sockopt(2), listen(2), recv(2), recvfrom(2), send(2),  sendto(2),  set-
       sockopt(2), shutdown(2), socket(2), socketpair(2)


----------------------------------------------------------------------------
 142 newselect     - sync I/O multiplexing
----------------------------------------------------------------------------

----------------------------------------------------------------------------
  34 nice          - change process priority
----------------------------------------------------------------------------
  mov  eax,034
  mov  ebx,increment
  int  80h

       nice  adds  inc  to  the nice value for the calling pid.  (A large nice
       value means a low priority.)  Only the superuser may specify a negative
       increment, or priority increase.

RETURN VALUE
       On  success,  zero is returned.  On error, -1 is returned, and errno is
       set appropriately.

ERRORS
       EPERM  A non-super user attempts to do a priority increase by supplying
              a negative inc.

CONFORMING TO
       SVr4,  SVID  EXT,  AT&T,  X/OPEN, BSD 4.3. However, the Linux and glibc
       (earlier than glibc 2.2.4) return  value  is  nonstandard,  see  below.
       SVr4 documents an additional EINVAL error code.

NOTES
       Note  that  the routine is documented in SUSv2 and POSIX 1003.1-2003 to
       return the new nice value, while the Linux syscall and (g)libc (earlier
       than glibc 2.2.4) routines return 0 on success.  The new nice value can
       be found using getpriority(2).  Note that an  implementation  in  which
       nice  returns  the new nice value can legitimately return -1.  To reli-
       ably detect an error, set errno to 0 before the  call,  and  check  its
       value when nice returns -1.

SEE ALSO
       nice(1), getpriority(2), setpriority(2), fork(2), renice(8)


----------------------------------------------------------------------------
 136 personality   - set the process execution domain
----------------------------------------------------------------------------
  mov  eax,136
  mov  ebx,persona
  int  80h

       Linux  supports different execution domains, or personalities, for each
       process. Among other things, execution domains tell Linux  how  to  map
       signal  numbers into signal actions. The execution domain system allows
       Linux to provide limited support  for  binaries  compiled  under  other
       Unix-like operating systems.

       This  function  will return the current personality when persona equals
       0xffffffff. Otherwise, it will make the execution domain referenced  by
       persona the new execution domain of the current process.

RETURN VALUE
       On success, the previous persona is returned. On error, -1 is returned,
       and errno is set appropriately.

ERRORS
       EINVAL The kernel was unable to change the personality.


FILES
       /usr/include/linux/personality.h


----------------------------------------------------------------------------
 172 prctl         - operations on a process
----------------------------------------------------------------------------
  option dword 
  arg2  dword 
  arg3  dword 
  arg4  dword 
  arg5  dword

  mov  eax,172
  mov  ebx,option
  mov  ecx,arg2
  mov  edx,arg3
  mov  esi,arg4
  mov  edi,arg5
  int  80h

       prctl is called with a first argument describing what to do (with  val-
       ues defined in <linux/prctl.h>), and further parameters with a signifi-
       cance depending on the first one.  The first argument can be:

       PR_SET_PDEATHSIG
              (since Linux 2.1.57) Set the parent process death signal of  the
              current  process  to  arg2  (either  a signal value in the range
              1..maxsig, or 0 to clear).  This is the signal that the  current
              process  will  get  when  its parent dies. This value is cleared
              upon a fork().

       PR_GET_PDEATHSIG
              (since Linux 2.3.15)  Read  the  current  value  of  the  parent
              process death signal into the (int *) arg2.

       PR_SET_DUMPABLE
              (Since  Linux 2.4) Set the state of the flag determining whether
              core dumps are produced for this process upon delivery of a sig-
              nal  whose  default  behaviour is to produce a core dump.  (Nor-
              mally this flag is set for a  process  by  default,  but  it  is
              cleared  when  a set-UID or set-GID program is executed and also
              by various system calls that manipulate process UIDs and  GIDs).
              arg2 must be either 0 (process is not dumpable) or 1 (process is
              dumpable).

       PR_GET_DUMPABLE
              (Since Linux 2.4) Return (as the function  result)  the  current
              state of the calling process's dumpable flag.

       PR_SET_KEEPCAPS
              Set  the  state of the process's "keep capabilities" flag, which
              determines whether the process's effective and  permitted  capa-
              bility  sets  are cleared when a change is made to the process's
              user IDs such that all of the  process's  real,  effective,  and
              saved  set  user  IDs  become non-zero when at least one of them
              previously had the value 0.  (By default, these credential  sets
              are  cleared).  arg2 must be either 0 (capabilities are cleared)
              or 1 (capabilities are kept).

       PR_GET_KEEPCAPS
              Return (as the function result) the current state of the calling
              process's "keep capabilities" flag.

RETURN VALUE
       PR_GET_DUMPABLE  and  PR_GET_KEEPCAPS  return  0  or 1 on success.  All
       other option values return 0 on success.  On error, -1 is returned, and
       errno is set appropriately.

ERRORS
       EINVAL The value of option is not recognized, or it is PR_SET_PDEATHSIG
              and arg2 is not zero or a signal number.

CONFORMING TO
       This call is Linux-specific.  IRIX has a prctl system call (also intro-
       duced  in  Linux  2.1.44  as irix_prctl on the MIPS architecture), with
       prototype

       ptrdiff_t prctl(int option, int arg2, int arg3);

       and options to get the maximum number of processes per  user,  get  the
       maximum  number  of  processors  the  calling process can use, find out
       whether a specified process is currently blocked, get or set the  maxi-
       mum stack size, etc., etc.

AVAILABILITY
       The  prctl()  systemcall  was  introduced in Linux 2.1.57.  There is no
       prctl() library call as yet.

SEE ALSO
       signal(2)


----------------------------------------------------------------------------
  26 ptrace        - process trace
----------------------------------------------------------------------------
  mov  eax,026
  mov  ebx,request
  mov  ecx,pid
  mov  edx,addr
  mov  esi,data
  int  80h

       The ptrace system call provides a means by which a parent  process  may
       observe  and  control the execution of another process, and examine and
       change its core image and registers.  It is primarily used to implement
       breakpoint debugging and system call tracing.

       The  parent  can  initiate  a  trace  by calling fork(2) and having the
       resulting  child  do  a  PTRACE_TRACEME,  followed  (typically)  by  an
       exec(3).   Alternatively,  the parent may commence trace of an existing
       process using PTRACE_ATTACH.

       While being traced, the child will stop each time a  signal  is  deliv-
       ered,  even if the signal is being ignored.  (The exception is SIGKILL,
       which has its usual effect.)  The parent will be notified at  its  next
       wait(2)  and  may  inspect  and  modify  the  child process while it is
       stopped.  The parent then causes  the  child  to  continue,  optionally
       ignoring  the  delivered  signal (or even delivering a different signal
       instead).

       When the parent is finished tracing, it can terminate  the  child  with
       PTRACE_KILL  or  cause  it  to continue executing in a normal, untraced
       mode via PTRACE_DETACH.

       The value of request determines the action to be performed:

       PTRACE_TRACEME
              Indicates that this process is to be traced by its parent.   Any
              signal  (except SIGKILL) delivered to this process will cause it
              to stop and its parent to be notified via wait.  Also, all  sub-
              sequent calls to exec by this process will cause a SIGTRAP to be
              sent to it, giving the parent a chance to  gain  control  before
              the  new program begins execution.  A process probably shouldn't
              make this request if its parent isn't  expecting  to  trace  it.
              (pid, addr, and data are ignored.)

       The  above request is used only by the child process; the rest are used
       only by the parent.  In the following requests, pid specifies the child
       process to be acted on.  For requests other than PTRACE_KILL, the child
       process must be stopped.

       PTRACE_PEEKTEXT, PTRACE_PEEKDATA
              Reads a word at the location addr in the child's memory, return-
              ing  the  word as the result of the ptrace call.  Linux does not
              have separate text and data address spaces, so the two  requests
              are currently equivalent.  (The argument data is ignored.)

       PTRACE_PEEKUSR
              Reads  a  word  at  offset  addr in the child's USER area, which
              holds the registers and other information about the process (see
              <linux/user.h>  and  <sys/user.h>).  The word is returned as the
              result of the ptrace call.  Typically the offset must  be  word-
              aligned,  though  this  might  vary  by  architecture.  (data is
              ignored.)

       PTRACE_POKETEXT, PTRACE_POKEDATA
              Copies the word data to location addr in the child's memory.  As
              above, the two requests are currently equivalent.

       PTRACE_POKEUSR
              Copies  the  word  data to offset addr in the child's USER area.
              As above, the offset must typically be word-aligned.   In  order
              to  maintain  the integrity of the kernel, some modifications to
              the USER area are disallowed.

       PTRACE_GETREGS, PTRACE_GETFPREGS
              Copies the child's general purpose or floating-point  registers,
              respectively,   to   location   data   in   the   parent.    See
              <linux/user.h> for information  on  the  format  of  this  data.
              (addr is ignored.)

       PTRACE_SETREGS, PTRACE_SETFPREGS
              Copies  the child's general purpose or floating-point registers,
              respectively,  from  location  data  in  the  parent.   As   for
              PTRACE_POKEUSER, some general purpose register modifications may
              be disallowed.  (addr is ignored.)

       PTRACE_CONT
              Restarts the stopped child process.  If data is non-zero and not
              SIGSTOP,  it  is  interpreted as a signal to be delivered to the
              child; otherwise, no signal is delivered.   Thus,  for  example,
              the  parent  can  control  whether a signal sent to the child is
              delivered or not.  (addr is ignored.)

       PTRACE_SYSCALL, PTRACE_SINGLESTEP
              Restarts the stopped child as for PTRACE_CONT, but arranges  for
              the child to be stopped at the next entry to or exit from a sys-
              tem call, or after execution of a  single  instruction,  respec-
              tively.  (The child will also, as usual, be stopped upon receipt
              of a signal.)  From the parent's  perspective,  the  child  will
              appear  to  have  been stopped by receipt of a SIGTRAP.  So, for
              PTRACE_SYSCALL, for example, the idea is to  inspect  the  argu-
              ments  to  the  system  call  at the first stop, then do another
              PTRACE_SYSCALL and inspect the return value of the  system  call
              at the second stop.  (addr is ignored.)

       PTRACE_KILL
              Sends  the  child a SIGKILL to terminate it.  (addr and data are
              ignored.)

       PTRACE_ATTACH
              Attaches to the process specified in pid,  making  it  a  traced
              "child"  of the current process; the behavior of the child is as
              if it had done a PTRACE_TRACEME.  The current  process  actually
              becomes the parent of the child process for most purposes (e.g.,
              it will receive notification of  child  events  and  appears  in
              ps(1)  output  as  the  child's parent), but a getppid(2) by the
              child will still return the pid of  the  original  parent.   The
              child  is  sent a SIGSTOP, but will not necessarily have stopped
              by the completion of this call; use wait to wait for  the  child
              to stop.  (addr and data are ignored.)

       PTRACE_DETACH
              Restarts  the  stopped  child  as  for  PTRACE_CONT,  but  first
              detaches from the process, undoing  the  reparenting  effect  of
              PTRACE_ATTACH, and the effects of PTRACE_TRACEME.  Although per-
              haps not intended, under Linux a traced child can be detached in
              this  way  regardless of which method was used to initiate trac-
              ing.  (addr is ignored.)

NOTES
       Although arguments to ptrace are interpreted according to the prototype
       given,  GNU  libc currently declares ptrace as a variadic function with
       only the request argument fixed.  This  means  that  unneeded  trailing
       arguments  may  be  omitted,  though doing so makes use of undocumented
       gcc(1) behavior.

       init(8), the process with pid 1, may not be traced.

       The layout of the contents of memory and the USER area  are  quite  OS-
       and architecture-specific.

       The  size of a "word" is determined by the OS variant (e.g., for 32-bit
       Linux it's 32 bits, etc.).

       Tracing causes a few subtle differences in the semantics of traced pro-
       cesses.   For  example, if a process is attached to with PTRACE_ATTACH,
       its original parent can no longer receive notification via wait when it
       stops,  and  there is no way for the new parent to effectively simulate
       this notification.

       This page documents the way the ptrace call works currently  in  Linux.
       Its behavior differs noticeably on other flavors of Unix.  In any case,
       use of ptrace is highly OS- and architecture-specific.

       The SunOS man page describes ptrace as "unique and  arcane",  which  it
       is.  The proc-based debugging interface present in Solaris 2 implements
       a superset of ptrace functionality in a more powerful and uniform  way.

RETURN VALUE
       On  success,  PTRACE_PEEK*  requests  return  the requested data, while
       other requests return zero.  On error,  all  requests  return  -1,  and
       errno(3)  is set appropriately.  Since the value returned by a success-
       ful PTRACE_PEEK* request may be -1, the caller must check  errno  after
       such requests to determine whether or not an error occurred.

ERRORS
       EPERM  The  specified  process cannot be traced.  This could be because
              the parent has insufficient privileges; non-root processes  can-
              not  trace  processes  that they cannot send signals to or those
              running setuid/setgid programs, for obvious  reasons.   Alterna-
              tively, the process may already be being traced, or be init (pid
              1).

       ESRCH  The specified process does not exist, or is not currently  being
              traced  by  the  caller,  or  is  not stopped (for requests that
              require that).

       EIO    request is invalid, or an attempt was made to read from or write
              to  an  invalid area in the parent's or child's memory, or there
              was a word-alignment violation, or an invalid signal was  speci-
              fied during a restart request.

       EFAULT There was an attempt to read from or write to an invalid area in
              the parent's or child's memory, probably because the area wasn't
              mapped  or  accessible.   Unfortunately,  under Linux, different
              variations of this fault will return EIO or EFAULT more or  less
              arbitrarily.

       EBUSY  (i386  only)  There  was  an  error with allocating or freeing a
              debug register.

SEE ALSO
       gdb(1), strace(1), execve(2), fork(2), signal(2), wait(2), exec(3)


----------------------------------------------------------------------------
  97 setpriority   - set program scheduling priority
----------------------------------------------------------------------------
  mov  eax,097
  mov  ebx,which
  mov  ecx,who
  int  80h

       The  scheduling  priority  of  the  process, process group, or user, as
       indicated by which and who is obtained with the  getpriority  call  and
       set   with  the  setpriority  call.   Which  is  one  of  PRIO_PROCESS,
       PRIO_PGRP, or PRIO_USER, and who is interpreted relative  to  which  (a
       process  identifier  for  PRIO_PROCESS,  process  group  identifier for
       PRIO_PGRP, and a user ID for PRIO_USER).  A zero value for who  denotes
       (respectively)  the  calling  process, the process group of the calling
       process, or the real user ID of the calling process.  Prio is  a  value
       in the range -20 to 20 (but see the Notes below).  The default priority
       is 0; lower priorities cause more favorable scheduling.

RETURN VALUE
       Since getpriority can legitimately return the value -1, it is necessary
       to clear the external variable errno prior to the call, then  check  it
       afterwards to determine if a -1 is an error or a legitimate value.  The
       setpriority call returns 0 if there is no error, or -1 if there is.

ERRORS
       ESRCH  No process was located using the which and who values specified.

       EINVAL Which was not one of PRIO_PROCESS, PRIO_PGRP, or PRIO_USER.

       In addition to the errors indicated above, setpriority may fail if:

       EPERM  A  process  was  located, but neither the effective nor the real
              user ID of the caller matches its effective user ID.

       EACCES A non super-user attempted to lower a process priority.

NOTES
       The details on the condition for EPERM depend on the system.  The above
       description  is  what SUSv3 says, and seems to be followed on all SYSV-
       like systems.  Linux requires the real or  effective  user  ID  of  the
       caller to match the real user of the process who (instead of its effec-
       tive user ID).  All BSD-like systems (SunOS 4.1.3, Ultrix 4.2, BSD 4.3,
       FreeBSD  4.3,  OpenBSD-2.5,  ...)  require the effective user ID of the
       caller to match the real or effective user ID of the process who.

       The actual priority range varies between kernel versions.  Linux before
       1.3.36  had -infinity..15. Linux since 1.3.43 has -20..19, and the sys-
       tem call getpriority returns 40..1 for  these  values  (since  negative
       numbers are error codes).  The library call converts N into 20-N.

       Including <sys/time.h> is not required these days, but increases porta-
       bility.  (Indeed, <sys/resource.h> defines the  rusage  structure  with
       fields of type struct timeval defined in <sys/time.h>.)

CONFORMING TO
       SVr4, 4.4BSD (these function calls first appeared in 4.2BSD).

SEE ALSO
       nice(1), fork(2), renice(8)

----------------------------------------------------------------------------
 190 vfork         - create a child process and block parent
----------------------------------------------------------------------------
    mov  eax,190
    int  80h

       The vfork() function has the same
       effect as fork(), except that the behaviour is undefined if the process
       created  by  vfork()  either modifies any data other than a variable of
       type pid_t used to store the return value from vfork(), or returns from
       the  function  in which vfork() was called, or calls any other function
       before successfully calling _exit() or one of the exec family of  func-
       tions.

ERRORS
       EAGAIN Too many processes - try again.

       ENOMEM There is insufficient swap space for the new process.

LINUX DESCRIPTION
       vfork,  just  like  fork(2),  creates  a  child  process of the calling
       process.  For details and return value and errors, see fork(2).

       vfork() is a special case of clone(2).  It is used to create  new  pro-
       cesses  without  copying the page tables of the parent process.  It may
       be useful in performance sensitive applications where a child  will  be
       created which then immediately issues an execve().

       vfork()  differs  from  fork  in that the parent is suspended until the
       child makes a call to execve(2) or _exit(2).  The child shares all mem-
       ory  with  its parent, including the stack, until execve() is issued by
       the child.  The child must not return from the current function or call
       exit(), but may call _exit().

       Signal  handlers  are inherited, but not shared.  Signals to the parent
       arrive after the child releases the parent.

BUGS
       It is rather unfortunate that Linux revived this spectre from the past.
       The  BSD  manpage  states:  "This  system  call will be eliminated when
       proper system sharing mechanisms  are  implemented.  Users  should  not
       depend  on  the  memory  sharing semantics of vfork as it will, in that
       case, be made synonymous to fork."

CONFORMING TO
       The vfork call may be a bit similar to calls  with  the  same  name  in
       other operating systems. The requirements put on vfork by the standards
       are weaker than those put on fork, so an implementation where  the  two
       are  synonymous is compliant. In particular, the programmer cannot rely
       on the parent remaining blocked until a call of execve() or _exit() and
       cannot rely on any specific behaviour w.r.t. shared memory.

SEE ALSO
       clone(2), execve(2), fork(2), wait(2)


----------------------------------------------------------------------------
 111 vhangup       - virtually hangup the current tty
----------------------------------------------------------------------------
  mov   eax,111
  int   80h

       vhangup simulates a hangup on the current terminal.  This call arranges
       for other users to have a "clean" tty at login time.

RETURN VALUE
       On success, zero is returned.  On error, -1 is returned, and  errno  is
       set appropriately.

ERRORS
       EPERM  The user is not the super-user.

CONFORMING TO
       This  call  is  Linux-specific,  and  should  not  be  used in programs
       intended to be portable.

SEE ALSO
       init(8)
