]> err.no Git - util-linux/commitdiff
ipc: remove .info file
authorKarel Zak <kzak@redhat.com>
Fri, 3 Dec 2010 12:02:40 +0000 (13:02 +0100)
committerKarel Zak <kzak@redhat.com>
Fri, 3 Dec 2010 12:02:40 +0000 (13:02 +0100)
Signed-off-by: Karel Zak <kzak@redhat.com>
sys-utils/ipc.info [deleted file]

diff --git a/sys-utils/ipc.info b/sys-utils/ipc.info
deleted file mode 100644 (file)
index a1fe498..0000000
+++ /dev/null
@@ -1,1107 +0,0 @@
-This is ipc.info, produced by makeinfo version 4.7 from ipc.texi.
-
-   This file documents the System V style inter process communication
-primitives available under linux.
-
-   Copyright (C) 1992  krishna balasubramanian
-
-   Permission is granted to use this material and the accompanying
-programs within the terms of the GNU GPL.
-
-INFO-DIR-SECTION Miscellaneous
-START-INFO-DIR-ENTRY
-* ipc: (ipc).           System V style inter process communication
-END-INFO-DIR-ENTRY
-
-\1f
-File: ipc.info,  Node: Top,  Next: Overview,  Prev: Notes,  Up: (dir)
-
-1 System V IPC.
-***************
-
-These facilities are provided to maintain compatibility with programs
-developed on system V unix systems and others that rely on these system
-V mechanisms to accomplish inter process communication (IPC).
-
-   The specifics described here are applicable to the Linux
-implementation.  Other implementations may do things slightly
-differently.
-
-* Menu:
-
-* Overview::           What is system V ipc? Overall mechanisms.
-* Messages::           System calls for message passing.
-* Semaphores::                 System calls for semaphores.
-* Shared Memory::      System calls for shared memory access.
-* Notes::              Miscellaneous notes.
-
-\1f
-File: ipc.info,  Node: Overview,  Next: example,  Prev: Top,  Up: Top
-
-1.1 Overview
-============
-
-System V IPC consists of three mechanisms:
-
-   * Messages : exchange messages with any process or server.
-
-   * Semaphores : allow unrelated processes to synchronize execution.
-
-   * Shared memory : allow unrelated processes to share memory.
-
-* Menu:
-
-* example::    Using shared memory.
-* perms::      Description of access permissions.
-* syscalls::    Overview of ipc system calls.
-
-   Access to all resources is permitted on the basis of permissions set
-up when the resource was created.
-
-   A resource here consists of message queue, a semaphore set (array)
-or a shared memory segment.
-
-   A resource must first be allocated by a creator before it is used.
-The creator can assign a different owner. After use the resource must
-be explicitly destroyed by the creator or owner.
-
-   A resource is identified by a numeric ID. Typically a creator
-defines a KEY that may be used to access the resource. The user process
-may then use this KEY in the "get" system call to obtain the ID for the
-corresponding resource. This ID is then used for all further access. A
-library call "ftok" is provided to translate pathnames or strings to
-numeric keys.
-
-   There are system and implementation defined limits on the number and
-sizes of resources of any given type. Some of these are imposed by the
-implementation and others by the system administrator when configuring
-the kernel (*Note msglimits::, *Note semlimits::, *Note shmlimits::).
-
-   There is an `msqid_ds', `semid_ds' or `shmid_ds' struct associated
-with each message queue, semaphore array or shared segment.  Each ipc
-resource has an associated `ipc_perm' struct which defines the creator,
-owner, access perms ..etc.., for the resource.  These structures are
-detailed in the following sections.
-
-\1f
-File: ipc.info,  Node: example,  Next: perms,  Prev: Overview,  Up: Overview
-
-1.2 example
-===========
-
-Here is a code fragment with pointers on how to use shared memory. The
-same methods are applicable to other resources.
-
-   In a typical access sequence the creator allocates a new instance of
-the resource with the `get' system call using the IPC_CREAT flag.
-
-creator process:
-     #include <sys/shm.h>
-     int id;
-     key_t key;
-     char proc_id = 'C';
-     int size = 0x5000;        /* 20 K */
-     int flags = 0664 | IPC_CREAT;             /* read-only for others */
-
-     key = ftok ("~creator/ipckey", proc_id);
-     id = shmget (key, size, flags);
-     exit (0); /* quit leaving resource allocated */
-
-Users then gain access to the resource using the same key.
-Client process:
-     #include <sys/shm.h>
-     char *shmaddr;
-     int id;
-     key_t key;
-     char proc_id = 'C';
-
-     key = ftok ("~creator/ipckey", proc_id);
-
-     id = shmget (key, 0, 004);                /* default size   */
-     if (id == -1)
-           perror ("shmget ...");
-
-     shmaddr = shmat (id, 0, SHM_RDONLY); /* attach segment for reading */
-     if (shmaddr == (char *) -1)
-           perror ("shmat ...");
-
-     local_var = *(shmaddr + 3);       /* read segment etc. */
-
-     shmdt (shmaddr);          /* detach segment */
-
-When the resource is no longer needed the creator should remove it.
-Creator/owner process 2:
-     key = ftok ("~creator/ipckey", proc_id)
-     id = shmget (key, 0, 0);
-     shmctl (id, IPC_RMID, NULL);
-
-\1f
-File: ipc.info,  Node: perms,  Next: syscalls,  Prev: example,  Up: Overview
-
-1.3 Permissions
-===============
-
-Each resource has an associated `ipc_perm' struct which defines the
-creator, owner and access perms for the resource.
-
-     struct ipc_perm
-             key_t key;    /* set by creator */
-             ushort uid;   /* owner euid and egid */
-             ushort gid;
-             ushort cuid;  /* creator euid and egid */
-             ushort cgid;
-             ushort mode;  /* access modes in lower 9 bits */
-             ushort seq;   /* sequence number */
-
-   The creating process is the default owner. The owner can be
-reassigned by the creator and has creator perms. Only the owner,
-creator or super-user can delete the resource.
-
-   The lowest nine bits of the flags parameter supplied by the user to
-the system call are compared with the values stored in `ipc_perms.mode'
-to determine if the requested access is allowed. In the case that the
-system call creates the resource, these bits are initialized from the
-user supplied value.
-
-   As for files, access permissions are specified as read, write and
-exec for user, group or other (though the exec perms are unused). For
-example 0624 grants read-write to owner, write-only to group and
-read-only access to others.
-
-   For shared memory, note that read-write access for segments is
-determined by a separate flag which is not stored in the `mode' field.
-Shared memory segments attached with write access can be read.
-
-   The `cuid', `cgid', `key' and `seq' fields cannot be changed by the
-user.
-
-\1f
-File: ipc.info,  Node: syscalls,  Next: Messages,  Prev: perms,  Up: Overview
-
-1.4 IPC system calls
-====================
-
-This section provides an overview of the IPC system calls. See the
-specific sections on each type of resource for details.
-
-   Each type of mechanism provides a "get", "ctl" and one or more "op"
-system calls that allow the user to create or procure the resource
-(get), define its behaviour or destroy it (ctl) and manipulate the
-resources (op).
-
-1.4.1 The "get" system calls
-----------------------------
-
-The `get' call typically takes a KEY and returns a numeric ID that is
-used for further access.  The ID is an index into the resource table. A
-sequence number is maintained and incremented when a resource is
-destroyed so that access using an obsolete ID is likely to fail.
-
-   The user also specifies the permissions and other behaviour
-charecteristics for the current access. The flags are or-ed with the
-permissions when invoking system calls as in:
-     msgflg = IPC_CREAT | IPC_EXCL | 0666;
-     id = msgget (key, msgflg);
-
-   * `key' : IPC_PRIVATE => new instance of resource is initialized.
-
-   * `flags' :
-          IPC_CREAT : resource created for KEY if it does not exist.
-
-          IPC_CREAT | IPC_EXCL : fail if resource exists for KEY.
-
-   * returns : an identifier used for all further access to the
-     resource.
-
-   Note that IPC_PRIVATE is not a flag but a special `key' that ensures
-(when the call is successful) that a new resource is created.
-
-   Use of IPC_PRIVATE does not make the resource inaccessible to other
-users. For this you must set the access permissions appropriately.
-
-   There is currently no way for a process to ensure exclusive access
-to a resource. IPC_CREAT | IPC_EXCL only ensures (on success) that a new
-resource was initialized. It does not imply exclusive access.
-
-See Also : *Note msgget::, *Note semget::, *Note shmget::.
-
-1.4.2 The "ctl" system calls
-----------------------------
-
-Provides or alters the information stored in the structure that
-describes the resource indexed by ID.
-
-     #include <sys/msg.h>
-     struct msqid_ds buf;
-     err = msgctl (id, IPC_STAT, &buf);
-     if (err)
-             !$#%*
-     else
-             printf ("creator uid = %d\n", buf.msg_perm.cuid);
-             ....
-
-Commands supported by all `ctl' calls:
-   * IPC_STAT : read info on resource  specified by id into user
-     allocated buffer. The user must have read access to the resource.
-
-   * IPC_SET : write info from buffer into resource data structure. The
-     user must be owner creator or super-user.
-
-   * IPC_RMID : remove resource. The user must be the owner, creator or
-     super-user.
-
-   The IPC_RMID command results in immediate removal of a message queue
-or semaphore array. Shared memory segments however, are only destroyed
-upon the last detach after IPC_RMID is executed.
-
-   The `semctl' call provides a number of command options that allow
-the user to determine or set the values of the semaphores in an array.
-
-See Also: *Note msgctl::, *Note semctl::, *Note shmctl::.
-
-1.4.3 The "op" system calls
----------------------------
-
-Used to send or receive messages, read or alter semaphore values,
-attach or detach shared memory segments.  The IPC_NOWAIT flag will
-cause the operation to fail with error EAGAIN if the process has to
-wait on the call.
-
-`flags' : IPC_NOWAIT  => return with error if a wait is required.
-
-See Also: *Note msgsnd::,*Note msgrcv::,*Note semop::,*Note shmat::,
-*Note shmdt::.
-
-\1f
-File: ipc.info,  Node: Messages,  Next: msgget,  Prev: syscalls,  Up: Top
-
-1.5 Messages
-============
-
-A message resource is described by a struct `msqid_ds' which is
-allocated and initialized when the resource is created. Some fields in
-`msqid_ds' can then be altered (if desired) by invoking `msgctl'.  The
-memory used by the resource is released when it is destroyed by a
-`msgctl' call.
-
-     struct msqid_ds
-         struct ipc_perm msg_perm;
-         struct msg *msg_first;  /* first message on queue (internal) */
-         struct msg *msg_last;   /* last message in queue (internal) */
-         time_t msg_stime;       /* last msgsnd time */
-         time_t msg_rtime;       /* last msgrcv time */
-         time_t msg_ctime;       /* last change time */
-         struct wait_queue *wwait; /* writers waiting (internal) */
-         struct wait_queue *rwait; /* readers waiting (internal) */
-         ushort msg_cbytes;      /* number of bytes used on queue */
-         ushort msg_qnum;        /* number of messages in queue */
-         ushort msg_qbytes;      /* max number of bytes on queue */
-         ushort msg_lspid;       /* pid of last msgsnd */
-         ushort msg_lrpid;       /* pid of last msgrcv */
-
-   To send or receive a message the user allocates a structure that
-looks like a `msgbuf' but with an array `mtext' of the required size.
-Messages have a type (positive integer) associated with them so that
-(for example) a listener can choose to receive only messages of a given
-type.
-
-     struct msgbuf
-         long mtype;      type of message (*Note msgrcv::).
-         char mtext[1];   message text .. why is this not a ptr?
-
-   The user must have write permissions to send and read permissions to
-receive messages on a queue.
-
-   When `msgsnd' is invoked, the user's message is copied into an
-internal struct `msg' and added to the queue. A `msgrcv' will then read
-this message and free the associated struct `msg'.
-
-* Menu:
-
-* msgget::
-* msgsnd::
-* msgrcv::
-* msgctl::
-* msglimits:: Implementation defined limits.
-
-\1f
-File: ipc.info,  Node: msgget,  Next: msgsnd,  Prev: Messages,  Up: Messages
-
-1.5.1 msgget
-------------
-
-A message queue is allocated by a msgget system call :
-
-     msqid = msgget (key_t key, int msgflg);
-
-   * `key': an integer usually got from `ftok()' or IPC_PRIVATE.
-
-   * `msgflg':
-          IPC_CREAT : used to create a new resource if it does not
-          already exist.
-
-          IPC_EXCL | IPC_CREAT : used to ensure failure of the call if
-          the resource already exists.
-
-          rwxrwxrwx : access permissions.
-
-   * returns: msqid (an integer used for all further access) on success.
-     -1 on failure.
-
-   A message queue is allocated if there is no resource corresponding
-to the given key. The access permissions specified are then copied into
-the `msg_perm' struct and the fields in `msqid_ds' initialized. The
-user must use the IPC_CREAT flag or key = IPC_PRIVATE, if a new
-instance is to be allocated. If a resource corresponding to KEY already
-exists, the access permissions are verified.
-
-Errors:
-EACCES : (procure) Do not have permission for requested access.
-EEXIST : (allocate) IPC_CREAT | IPC_EXCL specified and resource exists.
-EIDRM  : (procure) The resource was removed.
-ENOSPC : All id's are taken (max of MSGMNI id's system-wide).
-ENOENT : Resource does not exist and IPC_CREAT not specified.
-ENOMEM : A new `msqid_ds' was to be created but ... nomem.
-
-\1f
-File: ipc.info,  Node: msgsnd,  Next: msgrcv,  Prev: msgget,  Up: Messages
-
-1.5.2 msgsnd
-------------
-
-     int msgsnd (int msqid, struct msgbuf *msgp, int msgsz, int msgflg);
-
-   * `msqid' : id obtained by a call to msgget.
-
-   * `msgsz' : size of msg text (`mtext') in bytes.
-
-   * `msgp' : message to be sent. (msgp->mtype must be positive).
-
-   * `msgflg' : IPC_NOWAIT.
-
-   * returns : msgsz on success. -1 on error.
-
-   The message text and type are stored in the internal `msg'
-structure. `msg_cbytes', `msg_qnum', `msg_lspid', and `msg_stime'
-fields are updated. Readers waiting on the queue are awakened.
-
-Errors:
-EACCES : Do not have write permission on queue.
-EAGAIN : IPC_NOWAIT specified and queue is full.
-EFAULT : msgp not accessible.
-EIDRM  : The message queue was removed.
-EINTR  : Full queue ... would have slept but ... was interrupted.
-EINVAL : mtype < 1, msgsz > MSGMAX, msgsz < 0, msqid < 0 or unused.
-ENOMEM : Could not allocate space for header and text.
-\1f
-File: ipc.info,  Node: msgrcv,  Next: msgctl,  Prev: msgsnd,  Up: Messages
-
-1.5.3 msgrcv
-------------
-
-     int msgrcv (int msqid, struct msgbuf *msgp, int msgsz, long msgtyp,
-                       int msgflg);
-
-   * msqid  : id obtained by a call to msgget.
-
-   * msgsz  : maximum size of message to receive.
-
-   * msgp   : allocated by user to store the message in.
-
-   * msgtyp :
-          0 => get first message on queue.
-
-          > 0 => get first message of matching type.
-
-          < 0 => get message with least type  which is <= abs(msgtyp).
-
-   * msgflg :
-          IPC_NOWAIT : Return immediately if message not found.
-
-          MSG_NOERROR : The message is truncated if it is larger than
-          msgsz.
-
-          MSG_EXCEPT : Used with msgtyp > 0 to receive any msg except
-          of specified type.
-
-   * returns : size of message if found. -1 on error.
-
-   The first message that meets the `msgtyp' specification is
-identified. For msgtyp < 0, the entire queue is searched for the
-message with the smallest type.
-
-   If its length is smaller than msgsz or if the user specified the
-MSG_NOERROR flag, its text and type are copied to msgp->mtext and
-msgp->mtype, and it is taken off the queue.
-
-   The `msg_cbytes', `msg_qnum', `msg_lrpid', and `msg_rtime' fields
-are updated. Writers waiting on the queue are awakened.
-
-Errors:
-E2BIG  : msg bigger than msgsz and MSG_NOERROR not specified.
-EACCES : Do not have permission for reading the queue.
-EFAULT : msgp not accessible.
-EIDRM  : msg queue was removed.
-EINTR  : msg not found ... would have slept but ... was interrupted.
-EINVAL : msgsz > msgmax or msgsz < 0, msqid < 0 or unused.
-ENOMSG : msg of requested type not found and IPC_NOWAIT specified.
-
-\1f
-File: ipc.info,  Node: msgctl,  Next: msglimits,  Prev: msgrcv,  Up: Messages
-
-1.5.4 msgctl
-------------
-
-     int msgctl (int msqid, int cmd, struct msqid_ds *buf);
-
-   * msqid  : id obtained by a call to msgget.
-
-   * buf    : allocated by user for reading/writing info.
-
-   * cmd    : IPC_STAT, IPC_SET, IPC_RMID (*Note syscalls::).
-
-   IPC_STAT results in the copy of the queue data structure into the
-user supplied buffer.
-
-   In the case of IPC_SET, the queue size (`msg_qbytes') and the `uid',
-`gid', `mode' (low 9 bits) fields of the `msg_perm' struct are set from
-the user supplied values.  `msg_ctime' is updated.
-
-   Note that only the super user may increase the limit on the size of a
-message queue beyond MSGMNB.
-
-   When the queue is destroyed (IPC_RMID), the sequence number is
-incremented and all waiting readers and writers are awakened.  These
-processes will then return with `errno' set to EIDRM.
-
-Errors: EPERM  : Insufficient privilege to increase the size of the
-queue (IPC_SET) or remove it (IPC_RMID).
-EACCES : Do not have permission for reading the queue (IPC_STAT).
-EFAULT : buf not accessible (IPC_STAT, IPC_SET).
-EIDRM  : msg queue was removed.
-EINVAL : invalid cmd, msqid < 0 or unused.
-
-\1f
-File: ipc.info,  Node: msglimits,  Next: Semaphores,  Prev: msgctl,  Up: Messages
-
-1.5.5 Limis on Message Resources
---------------------------------
-
-Sizeof various structures:
-     msqid_ds        52   /* 1 per message  queue .. dynamic */
-
-     msg             16   /* 1 for each message in system .. dynamic */
-
-     msgbuf           8   /* allocated by user */
-
-Limits
-   * MSGMNI : number of message queue identifiers ... policy.
-
-   * MSGMAX : max size of message.  Header and message space allocated
-     on one page.  MSGMAX = (PAGE_SIZE - sizeof(struct msg)).
-     Implementation maximum MSGMAX = 4080.
-
-   * MSGMNB : default max size of a message queue ... policy.  The
-     super-user can increase the size of a queue beyond MSGMNB by a
-     `msgctl' call.
-
-Unused or unimplemented:
-MSGTQL  max number of message headers system-wide.
-MSGPOOL total size in bytes of msg pool.
-
-\1f
-File: ipc.info,  Node: Semaphores,  Next: semget,  Prev: msglimits,  Up: Top
-
-1.6 Semaphores
-==============
-
-Each semaphore has a value >= 0. An id provides access to an array of
-`nsems' semaphores. Operations such as read, increment or decrement
-semaphores in a set are performed by the `semop' call which processes
-`nsops' operations at a time. Each operation is specified in a struct
-`sembuf' described below. The operations are applied only if all of
-them succeed.
-
-   If you do not have a need for such arrays, you are probably better
-off using the `test_bit', `set_bit' and  `clear_bit' bit-operations
-defined in <asm/bitops.h>.
-
-   Semaphore operations may also be qualified by a SEM_UNDO flag which
-results in the operation being undone when the process exits.
-
-   If a decrement cannot go through, a process will be put to sleep on
-a queue waiting for the `semval' to increase unless it specifies
-IPC_NOWAIT. A read operation can similarly result in a sleep on a queue
-waiting for `semval' to become 0. (Actually there are two queues per
-semaphore array).
-
-A semaphore array is described by:
-     struct semid_ds
-       struct ipc_perm sem_perm;
-       time_t          sem_otime;      /* last semop time */
-       time_t          sem_ctime;      /* last change time */
-       struct wait_queue *eventn;        /* wait for a semval to increase */
-       struct wait_queue *eventz;      /* wait for a semval to become 0 */
-       struct sem_undo  *undo;         /* undo entries */
-       ushort          sem_nsems;      /* no. of semaphores in array */
-
-Each semaphore is described internally by :
-     struct sem
-       short   sempid;         /* pid of last semop() */
-       ushort  semval;         /* current value */
-       ushort  semncnt;        /* num procs awaiting increase in semval */
-       ushort  semzcnt;        /* num procs awaiting semval = 0 */
-
-* Menu:
-
-* semget::
-* semop::
-* semctl::
-* semlimits:: Limits imposed by this implementation.
-
-\1f
-File: ipc.info,  Node: semget,  Next: semop,  Prev: Semaphores,  Up: Semaphores
-
-1.6.1 semget
-------------
-
-A semaphore array is allocated by a semget system call:
-
-     semid = semget (key_t key, int nsems, int semflg);
-
-   * `key' : an integer usually got from `ftok' or IPC_PRIVATE
-
-   * `nsems' :
-          # of semaphores in array (0 <= nsems <= SEMMSL <= SEMMNS)
-
-          0 => dont care can be used when not creating the resource.
-          If successful you always get access to the entire array
-          anyway.
-
-   * semflg :
-          IPC_CREAT used to create a new resource
-
-          IPC_EXCL used with IPC_CREAT to ensure failure if the
-          resource exists.
-
-          rwxrwxrwx  access permissions.
-
-   * returns : semid on success. -1 on failure.
-
-   An array of nsems semaphores is allocated if there is no resource
-corresponding to the given key. The access permissions specified are
-then copied into the `sem_perm' struct for the array along with the
-user-id etc. The user must use the IPC_CREAT flag or key = IPC_PRIVATE
-if a new resource is to be created.
-
-Errors:
-EINVAL : nsems not in above range (allocate).
-nsems greater than number in array (procure).
-EEXIST : (allocate) IPC_CREAT | IPC_EXCL specified and resource exists.
-EIDRM  : (procure) The resource was removed.
-ENOMEM : could not allocate space for semaphore array.
-ENOSPC : No arrays available (SEMMNI), too few semaphores available
-(SEMMNS).
-ENOENT : Resource does not exist and IPC_CREAT not specified.
-EACCES : (procure) do not have permission for specified access.
-
-\1f
-File: ipc.info,  Node: semop,  Next: semctl,  Prev: semget,  Up: Semaphores
-
-1.6.2 semop
------------
-
-Operations on semaphore arrays are performed by calling semop :
-
-     int semop (int semid, struct sembuf *sops, unsigned nsops);
-
-   * semid : id obtained by a call to semget.
-
-   * sops : array of semaphore operations.
-
-   * nsops : number of operations in array (0 < nsops < SEMOPM).
-
-   * returns : semval for last operation. -1 on failure.
-
-Operations are described by a structure sembuf:
-     struct sembuf
-         ushort  sem_num;        /* semaphore index in array */
-         short   sem_op;         /* semaphore operation */
-         short   sem_flg;        /* operation flags */
-
-   The value `sem_op' is to be added (signed) to the current value
-semval of the semaphore with index sem_num (0 .. nsems -1) in the set.
-Flags recognized in sem_flg are IPC_NOWAIT and SEM_UNDO.
-
-Two kinds of operations can result in wait:
-  1. If sem_op is 0 (read operation) and semval is non-zero, the process
-     sleeps on a queue waiting for semval to become zero or returns with
-     error EAGAIN if (IPC_NOWAIT | sem_flg) is true.
-
-  2. If (sem_op < 0) and (semval + sem_op < 0), the process either
-     sleeps on a queue waiting for semval to increase or returns with
-     error EAGAIN if (sem_flg & IPC_NOWAIT) is true.
-
-   The array sops is first read in and preliminary checks performed on
-the arguments. The operations are parsed to determine if any of them
-needs write permissions or requests an undo operation.
-
-   The operations are then tried and the process sleeps if any operation
-that does not specify IPC_NOWAIT cannot go through. If a process sleeps
-it repeats these checks on waking up. If any operation that requests
-IPC_NOWAIT, cannot go through at any stage, the call returns with errno
-set to EAGAIN.
-
-   Finally, operations are committed when all go through without an
-intervening sleep. Processes waiting on the zero_queue or
-increment_queue are awakened if any of the semval's becomes zero or is
-incremented respectively.
-
-Errors:
-E2BIG  : nsops > SEMOPM.
-EACCES : Do not have permission for requested (read/alter) access.
-EAGAIN : An operation with IPC_NOWAIT specified could not go through.
-EFAULT : The array sops is not accessible.
-EFBIG  : An operation had semnum >= nsems.
-EIDRM  : The resource was removed.
-EINTR  : The process was interrupted on its way to a wait queue.
-EINVAL : nsops is 0, semid < 0 or unused.
-ENOMEM : SEM_UNDO requested. Could not allocate space for undo
-structure.
-ERANGE : sem_op + semval > SEMVMX for some operation.
-
-\1f
-File: ipc.info,  Node: semctl,  Next: semlimits,  Prev: semop,  Up: Semaphores
-
-1.6.3 semctl
-------------
-
-     int semctl (int semid, int semnum, int cmd, union semun arg);
-
-   * semid : id obtained by a call to semget.
-
-   * cmd :
-          GETPID  return pid for the process that executed the last
-          semop.
-
-          GETVAL  return semval of semaphore with index semnum.
-
-          GETNCNT return number of processes waiting for semval to
-          increase.
-
-          GETZCNT return number of processes waiting for semval to
-          become 0
-
-          SETVAL  set semval = arg.val.
-
-          GETALL  read all semval's into arg.array.
-
-          SETALL  set all semval's with values given in arg.array.
-
-   * returns : 0 on success or as given above. -1 on failure.
-
-   The first 4 operate on the semaphore with index semnum in the set.
-The last two operate on all semaphores in the set.
-
-   `arg' is a union :
-     union semun
-         int val;               value for SETVAL.
-         struct semid_ds *buf;  buffer for IPC_STAT and IPC_SET.
-         ushort *array;         array for GETALL and SETALL
-
-   * IPC_SET, SETVAL, SETALL : sem_ctime is updated.
-
-   * SETVAL, SETALL : Undo entries are cleared for altered semaphores in
-     all processes. Processes sleeping on the wait queues are awakened
-     if a semval becomes 0 or increases.
-
-   * IPC_SET : sem_perm.uid, sem_perm.gid, sem_perm.mode are updated
-     from user supplied values.
-
-Errors: EACCES : do not have permission for specified access.
-EFAULT : arg is not accessible.
-EIDRM  : The resource was removed.
-EINVAL : semid < 0 or semnum < 0 or semnum >= nsems.
-EPERM  : IPC_RMID, IPC_SET ... not creator, owner or super-user.
-ERANGE : arg.array[i].semval > SEMVMX or < 0 for some i.
-
-\1f
-File: ipc.info,  Node: semlimits,  Next: Shared Memory,  Prev: semctl,  Up: Semaphores
-
-1.6.4 Limits on Semaphore Resources
------------------------------------
-
-Sizeof various structures:
-     semid_ds    44   /* 1 per semaphore array .. dynamic */
-     sem          8   /* 1 for each semaphore in system .. dynamic */
-     sembuf       6   /* allocated by user */
-     sem_undo    20   /* 1 for each undo request .. dynamic */
-
-Limits :
-   * SEMVMX  32767  semaphore maximum value (short).
-
-   * SEMMNI  number of semaphore identifiers (or arrays) system
-     wide...policy.
-
-   * SEMMSL  maximum  number  of semaphores per id.  1 semid_ds per
-     array, 1 struct sem per semaphore => SEMMSL =  (PAGE_SIZE -
-     sizeof(semid_ds)) / sizeof(sem).  Implementation maximum SEMMSL =
-     500.
-
-   * SEMMNS  maximum number of semaphores system wide ... policy.
-     Setting SEMMNS >= SEMMSL*SEMMNI makes it irrelevent.
-
-   * SEMOPM    Maximum number of operations in one semop
-     call...policy.
-
-Unused or unimplemented:
-SEMAEM  adjust on exit max value.
-SEMMNU  number of undo structures system-wide.
-SEMUME  maximum number of undo entries per process.
-
-\1f
-File: ipc.info,  Node: Shared Memory,  Next: shmget,  Prev: semlimits,  Up: Top
-
-1.7 Shared Memory
-=================
-
-Shared memory is distinct from the sharing of read-only code pages or
-the sharing of unaltered data pages that is available due to the
-copy-on-write mechanism. The essential difference is that the shared
-pages are dirty (in the case of Shared memory) and can be made to
-appear at a convenient location in the process' address space.
-
-A shared segment is described by :
-     struct shmid_ds
-         struct  ipc_perm shm_perm;
-         int     shm_segsz;              /* size of segment (bytes) */
-         time_t  shm_atime;              /* last attach time */
-         time_t  shm_dtime;              /* last detach time */
-         time_t  shm_ctime;              /* last change time */
-         ulong   *shm_pages;             /* internal page table */
-         ushort  shm_cpid;               /* pid, creator */
-         ushort  shm_lpid;               /* pid, last operation */
-         short   shm_nattch;             /* no. of current attaches */
-
-   A shmget allocates a shmid_ds and an internal page table. A shmat
-maps the segment into the process' address space with pointers into the
-internal page table and the actual pages are faulted in as needed. The
-memory associated with the segment must be explicitly destroyed by
-calling shmctl with IPC_RMID.
-
-* Menu:
-
-* shmget::
-* shmat::
-* shmdt::
-* shmctl::
-* shmlimits:: Limits imposed by this implementation.
-
-\1f
-File: ipc.info,  Node: shmget,  Next: shmat,  Prev: Shared Memory,  Up: Shared Memory
-
-1.7.1 shmget
-------------
-
-A shared memory segment is allocated by a shmget system call:
-
-     int shmget(key_t key, int size, int shmflg);
-
-   * key : an integer usually got from `ftok' or IPC_PRIVATE
-
-   * size : size of the segment in bytes (SHMMIN <= size <= SHMMAX).
-
-   * shmflg :
-          IPC_CREAT used to create a new resource
-
-          IPC_EXCL used with IPC_CREAT to ensure failure if the
-          resource exists.
-
-          rwxrwxrwx  access permissions.
-
-   * returns : shmid on success. -1 on failure.
-
-   A descriptor for a shared memory segment is allocated if there isn't
-one corresponding to the given key. The access permissions specified are
-then copied into the `shm_perm' struct for the segment along with the
-user-id etc. The user must use the IPC_CREAT flag or key = IPC_PRIVATE
-to allocate a new segment.
-
-   If the segment already exists, the access permissions are verified,
-and a check is made to see that it is not marked for destruction.
-
-   `size' is effectively rounded up to a multiple of PAGE_SIZE as shared
-memory is allocated in pages.
-
-Errors:
-EINVAL : (allocate) Size not in range specified above.
-(procure) Size greater than size of segment.
-EEXIST : (allocate) IPC_CREAT | IPC_EXCL specified and resource exists.
-EIDRM  : (procure) The resource is marked destroyed or was removed.
-ENOSPC : (allocate) All id's are taken (max of SHMMNI id's system-wide).
-Allocating a segment of the requested size would exceed the system wide
-limit on total shared memory (SHMALL).
-ENOENT : (procure) Resource does not exist and IPC_CREAT not specified.
-EACCES : (procure) Do not have permission for specified access.
-ENOMEM : (allocate) Could not allocate memory for shmid_ds or pg_table.
-
-\1f
-File: ipc.info,  Node: shmat,  Next: shmdt,  Prev: shmget,  Up: Shared Memory
-
-1.7.2 shmat
------------
-
-Maps a shared segment into the process' address space.
-
-     char *virt_addr;
-     virt_addr =  shmat (int shmid, char *shmaddr, int shmflg);
-
-   * shmid : id got from call to shmget.
-
-   * shmaddr : requested attach address.
-     If shmaddr is 0 the system finds an unmapped region.
-     If a non-zero value is indicated the value must be page
-     aligned or the user must specify the SHM_RND flag.
-
-   * shmflg :
-     SHM_RDONLY : request read-only attach.
-     SHM_RND : attach address is rounded DOWN to a multiple of SHMLBA.
-
-   * returns: virtual address of attached segment. -1 on failure.
-
-   When shmaddr is 0, the attach address is determined by finding an
-unmapped region in the address range 1G to 1.5G, starting at 1.5G and
-coming down from there. The algorithm is very simple so you are
-encouraged to avoid non-specific attaches.
-
-Algorithm:
-     Determine attach address as described above.
-     Check region (shmaddr, shmaddr + size) is not mapped and allocate
-     page tables (undocumented SHM_REMAP flag!).
-     Map the region by setting up pointers into the internal page table.
-     Add a descriptor for the attach to the task struct for the process.
-     `shm_nattch', `shm_lpid', `shm_atime' are updated.
-
-Notes:
-The `brk' value is not altered.  The segment is automatically detached
-when the process exits.  The same segment may be attached as read-only
-or read-write and more than once in the process' address space.  A
-shmat can succeed on a segment marked for destruction.  The request for
-a particular type of attach is made using the SHM_RDONLY flag.  There
-is no notion of a write-only attach. The requested attach permissions
-must fall within those allowed by `shm_perm.mode'.
-
-Errors:
-EACCES : Do not have permission for requested access.
-EINVAL : shmid < 0 or unused, shmaddr not aligned, attach at brk failed.
-EIDRM  : resource was removed.
-ENOMEM : Could not allocate memory for descriptor or page tables.
-
-\1f
-File: ipc.info,  Node: shmdt,  Next: shmctl,  Prev: shmat,  Up: Shared Memory
-
-1.7.3 shmdt
------------
-
-     int shmdt (char *shmaddr);
-
-   * shmaddr : attach address of segment (returned by shmat).
-
-   * returns : 0 on success. -1 on failure.
-
-   An attached segment is detached and `shm_nattch' decremented. The
-occupied region in user space is unmapped. The segment is destroyed if
-it is marked for destruction and `shm_nattch' is 0.  `shm_lpid' and
-`shm_dtime' are updated.
-
-Errors:
-EINVAL : No shared memory segment attached at shmaddr.
-
-\1f
-File: ipc.info,  Node: shmctl,  Next: shmlimits,  Prev: shmdt,  Up: Shared Memory
-
-1.7.4 shmctl
-------------
-
-Destroys allocated segments. Reads/Writes the control structures.
-
-     int shmctl (int shmid, int cmd, struct shmid_ds *buf);
-
-   * shmid : id got from call to shmget.
-
-   * cmd : IPC_STAT, IPC_SET, IPC_RMID (*Note syscalls::).
-          IPC_SET : Used to set the owner uid, gid, and shm_perms.mode
-          field.
-
-          IPC_RMID : The segment is marked destroyed. It is only
-          destroyed on the last detach.
-
-          IPC_STAT : The shmid_ds structure is copied into the user
-          allocated buffer.
-
-   * buf : used to read (IPC_STAT) or write (IPC_SET) information.
-
-   * returns : 0 on success, -1 on failure.
-
-   The user must execute an IPC_RMID shmctl call to free the memory
-allocated by the shared segment. Otherwise all the pages faulted in
-will continue to live in memory or swap.
-
-Errors:
-EACCES : Do not have permission for requested access.
-EFAULT : buf is not accessible.
-EINVAL : shmid < 0 or unused.
-EIDRM  : identifier destroyed.
-EPERM  : not creator, owner or super-user (IPC_SET, IPC_RMID).
-
-\1f
-File: ipc.info,  Node: shmlimits,  Next: Notes,  Prev: shmctl,  Up: Shared Memory
-
-1.7.5 Limits on Shared Memory Resources
----------------------------------------
-
-Limits:
-   * SHMMNI  max num of shared segments system wide ... 4096.
-
-   * SHMMAX  max shared memory segment size (bytes) ... 4M
-
-   * SHMMIN  min shared memory segment size (bytes).  1 byte (though
-     PAGE_SIZE is the effective minimum size).
-
-   * SHMALL  max shared mem system wide (in pages) ... policy.
-
-   * SHMLBA  segment low boundary address multiple.  Must be page
-     aligned. SHMLBA = PAGE_SIZE.
-   Unused or unimplemented:
-SHMSEG : maximum number of shared segments per process.
-
-\1f
-File: ipc.info,  Node: Notes,  Next: Top,  Prev: shmlimits,  Up: Top
-
-1.8 Miscellaneous Notes
-=======================
-
-The system calls are mapped into one - `sys_ipc'. This should be
-transparent to the user.
-
-1.8.1 Semaphore `undo' requests
--------------------------------
-
-There is one sem_undo structure associated with a process for each
-semaphore which was altered (with an undo request) by the process.
-`sem_undo' structures are freed only when the process exits.
-
-   One major cause for unhappiness with the undo mechanism is that it
-does not fit in with the notion of having an atomic set of operations
-on an array. The undo requests for an array and each semaphore therein
-may have been accumulated over many `semop' calls. Thus use the undo
-mechanism with private semaphores only.
-
-   Should the process sleep in `exit' or should all undo operations be
-applied with the IPC_NOWAIT flag in effect?  Currently  those undo
-operations which go through immediately are applied and those that
-require a wait are ignored silently.
-
-1.8.2 Shared memory, `malloc' and the `brk'.
---------------------------------------------
-
-Note that since this section was written the implementation was changed
-so that non-specific attaches are done in the region 1G - 1.5G. However
-much of the following is still worth thinking about so I left it in.
-
-   On many systems, the shared memory is allocated in a special region
-of the address space ... way up somewhere. As mentioned earlier, this
-implementation attaches shared segments at the lowest possible address.
-Thus if you plan to use `malloc', it is wise to malloc a large space
-and then proceed to attach the shared segments. This way malloc sets
-the brk sufficiently above the region it will use.
-
-   Alternatively you can use `sbrk' to adjust the `brk' value as you
-make shared memory attaches. The implementation is not very smart about
-selecting attach addresses. Using the system default addresses will
-result in fragmentation if detaches do not occur in the reverse
-sequence as attaches.
-
-   Taking control of the matter is probably best. The rule applied is
-that attaches are allowed in unmapped regions other than in the text
-space (see <a.out.h>). Also remember that attach addresses and segment
-sizes are multiples of PAGE_SIZE.
-
-   One more trap (I quote Bruno on this). If you use malloc() to get
-space for your shared memory (ie. to fix the `brk'), you must ensure you
-get an unmapped address range. This means you must mallocate more memory
-than you had ever allocated before. Memory returned by malloc(), used,
-then freed by free() and then again returned by malloc is no good.
-Neither is calloced memory.
-
-   Note that a shared memory region remains a shared memory region until
-you unmap it. Attaching a segment at the `brk' and calling malloc after
-that will result in an overlap of what malloc thinks is its space with
-what is really a shared memory region. For example in the case of a
-read-only attach, you will not be able to write to the overlapped
-portion.
-
-1.8.3 Fork, exec and exit
--------------------------
-
-On a fork, the child inherits attached shared memory segments but not
-the semaphore undo information.
-
-   In the case of an exec, the attached shared segments are detached.
-The sem undo information however remains intact.
-
-   Upon exit, all attached shared memory segments are detached.  The
-adjust values in the undo structures are added to the relevant semvals
-if the operations are permitted. Disallowed operations are ignored.
-
-1.8.4 Other Features
---------------------
-
-These features of the current implementation are likely to be modified
-in the future.
-
-   The SHM_LOCK and SHM_UNLOCK flag are available (super-user) for use
-with the `shmctl' call to prevent swapping of a shared segment. The user
-must fault in any pages that are required to be present after locking
-is enabled.
-
-   The IPC_INFO, MSG_STAT, MSG_INFO, SHM_STAT, SHM_INFO, SEM_STAT,
-SEMINFO `ctl' calls are used by the `ipcs' program to provide
-information on allocated resources. These can be modified as needed or
-moved to a proc file system interface.
-
-
-
-
-   Thanks to Ove Ewerlid, Bruno Haible, Ulrich Pegelow and Linus
-Torvalds for ideas, tutorials, bug reports and fixes, and merriment.
-And more thanks to Bruno.
-
-
-\1f
-Tag Table:
-Node: Top\7f469
-Node: Overview\7f1171
-Node: example\7f3013
-Node: perms\7f4490
-Node: syscalls\7f6055
-Node: Messages\7f9540
-Node: msgget\7f11580
-Node: msgsnd\7f12976
-Node: msgrcv\7f13956
-Node: msgctl\7f15667
-Node: msglimits\7f16887
-Node: Semaphores\7f17776
-Node: semget\7f19740
-Node: semop\7f21305
-Node: semctl\7f23881
-Node: semlimits\7f25651
-Node: Shared Memory\7f26805
-Node: shmget\7f28295
-Node: shmat\7f30102
-Node: shmdt\7f32151
-Node: shmctl\7f32696
-Node: shmlimits\7f33839
-Node: Notes\7f34502
-\1f
-End Tag Table