|
|
|
ftn/datapool(5) -- Fortran Interprocess Data Sharing
|
|
Each datapool item, when compiled, will be turned into a separate external symbol so it can be correctly associated with the same symbol declared in other program units without being affected by its relative order in the datapool. In one blockdata subprogram, and in only one, a datapool must be defined as to its exact number of items, sizes, and relative order. This will be used as the basis for sharing the datapool with other processes wishing to access the same data. Each blockdata can contain... |
|
debug_group(5) -- Compiler options for debugging
|
|
cc(1), CC(1), f77(1), f90(1) PPPPaaaaggggeeee 4444 |
|
|
DIFFsource(5) -- archive of DIFF sources
|
|
/usr/share/src/gnutools/diff Directory of sources for port of DIFF version 1.15 to Silicon Graphics systems. This source is part of the eoe.src.gnutools subsystem. |
|
dominance(5) -- MAC label comparison policy
|
|
On systems with mandatory access control (MAC) enabled, the set of all possible Mandatory Access Control (MAC) labels constitutes a lattice, where a lattice is defined to be a partially ordered set for which there exists, for every pair of elements in the set, a greatest lower bound (GLB) and a least upper bound (LUB). A partial ordering over a set is defined by a relation that has the following three properties: reflexive, antisymmetric, transitive. The reflexive property states that every elem... |
|
dplace(5) -- NUMA placement specification
|
|
An example placement file describing two memories and two threads might look like: # placement specification file # set up 2 memories which are close memories 2 in topology cube # set up 2 threads threads 2 # run the first thread on the 2nd memory run thread 0 on memory 1 # run the 2nd thread on the first memory run thread 1 on memory 0 This specification, when used for initial placement, would request 2 nearby memories from the operating system. At creation, the threads are requested to run on ... |
|
dso(5) -- Dynamic Shared Object (DSO)
|
|
This man page describes Dynamic Shared Objects (DSOs). It is divided into the following 4 sections: * Overview * Linking and building DSOs * Performance considerations * Frequently asked questions |
|
dump(5) -- incremental dump format
|
|
Tapes used by dump and restore(1M) contain: a header record two groups of bit map records a group of records describing directories a group of records describing files The format of the header record and of the first record of each description as given in the include file is: #define TP_BSIZE 1024 #define NTREC 10 #define LBLSIZE 16 #define NAMELEN 64 #define TS_TAPE 1 #define TS_INODE 2 #define TS_BITS 3 #define TS_ADDR 4 #define TS_END 5 #define TS_CLRI 6 #define MAGI... |
|
elspec(5) -- ELF Layout specification
|
|
It is often desirable to specify the exact layout of an executable file. Some of the uses of this might be embedded systems, thread-local data layout, reducing cache conflicts, reducing false sharing, reducing memory utilization. The current linker allows exact specification of layout via the ELF Layout Specification language. |
|
environ(5) -- user environment
|
|
cat(1), chrtbl(1M), colltbl(1M), date(1), ed(1), fmtmsg(1), gencat(1), gettxt(1), login(1), ls(1), mkmsgs(1), mm(1), montbl(1M), nice(1), nohup(1), sh(1), sort(1), srchtxt(1), time(1), vi(1), wchrtbl(1M), exec(2), addseverity(3C), catgets(3C), catopen(3C), ctime(3C), ctype(3C), fmtmsg(3C), getdate(3C), getnetpath(3N), gettxt(3C), localeconv(3C), mbchar(3C), mktime(3C), printf(3S), scanf(3S), setlocale(3C), strcoll(3C), strftime(3C), strtod(3C), strxfrm(3C), netconfig(4), passwd(4), profile(4), s... |
|
esp(5) -- Embedded Support Partner
|
|
In order to reduce potential security breaches that ESP may cause, SGI asked RSA Security, Inc. to perform an evaluation of ESP. Pursuant to the evaluation, SGI implemented a wide range of recommendations from RSA Security, including: o Validating user permissions of process for proactive actions and disabling actions by root o Implementing reverse DNS lookup for both the Web server and ESP SGM o HMAC/MD5 digital signature of all data transfers to the ESP SGM o Disabling of login attempts with t... |
|
extacct(5) -- introduction to IRIX extended accounting features
|
|
The following steps are required to set up session or extended process accounting: * Enable session and/or extended process accounting in the kernel by using the systune(1M) utility to set the do_sessacct and/or do_extpacct parameters to non-zero values. Page 2 extacct(5) extacct(5) * Use the inst(1M) utility to install the eoe.sw.audit subsystem from your IRIX distribution media. This will add the special components required for the system audit trail facility to your system. It will be necessa... |
|
fcntl(5) -- file control options
|
|
The fcntl.h header defines the following requests and arguments for use by the functions fcntl (see fcntl(2)) and open (see open(2)). Values for cmd used by fcntl (the following values are unique): F_DUPFD Duplicate file descriptor F_GETFD Get file descriptor flags F_SETFD Set file descriptor flags F_GETFL Get file status flags F_SETFL Set file status flags F_GETLK Get record locking information F_SETLK Set record locking information F_SETLKW Set record locking information; wait if blocked F_ALL... |
|
ftn/ftn_mpio(5) -- Fortran Multi-Threaded I/O
|
|
Calvin Vu PPPPaaaaggggeeee 3333 |
|
gp_overflow(5) -- GP Overflow Errors
|
|
GP overflow is reported by the linker with one of several error messages: GP-relative sections overflow by 0x??? bytes. Please recompile with a smaller -G value. GOT overflow: please relink with -multigot. GOT unreachable: please relink with -multigot. These messages all indicate that the code being linked contains more than 64KB of GP-relative data area (see the next section), and attempts to reference it with a signed 16-bit displacement from the GP register. In the past we recommended recompi... |
|
grio(5) -- guaranteed-rate I/O
|
|
The example in this section describes a method of laying out the disks, filesystem, and real-time file that enables the greatest number of processes to obtain guarantees on a single file concurrently. It is not necessary to construct a file in this manner in order to use GRIO, however fewer processes can obtain rate guarantees on the file as a result. It is also not necessary to use a real-time file, however guarantees obtained on non-real time files can only be considered to be "soft" guarant... |
