Concurrent Computer Corporation
CXUX 7.1 Release Notes
CXUX_7.1 Products are:
cx_7.1 gdb_7.1 ix25_7.1 svvs_tests_7.1
cx_rt_7.1 gpib_7.1 nfs_7.1 vsx_tests_7.1
dr11w_7.1 hc_7.1 osi_lan_7.1 vt_7.1
================================================================================
CX/UX -
VERSION 7.1
RELEASE NOTES
Harris Computer Systems Division
1. Introduction
CX/UX Release 7.1 is a complete new release of the CX/UX
operating system and its optional products. It requires a
complete regeneration of your system. This release
incorporates major system changes and support for new
products.
Please read this entire document and all applicable optional
product release notes before you proceed with the
installation.
The CX/UX Release 7.1 package contains a minimum of two
magnetic tapes: (1) a boot tape marked boot/miniroot, and
(2) a products tape marked products. Each tape is described
briefly in the next two paragraphs.
1.1 Boot/miniroot tape
The boot/miniroot tape is in dd format and contains two
partitions separated by a tape mark. One partition contains
the bootstrap file system, and the second partition contains
the miniroot file system. With the bootstrap file system,
you can format disks and copy files from tape to disk. The
miniroot file system contains a portion of the operating
system and utilities needed to boot the system.
__________
- These release notes cover the following products: cx
- 1 -
CX/UX 7.1 Release Notes
1.2 Products tape
This tape is in cpio format and contains the root, /usr, and
/var file systems plus optional products if purchased. The
root files, /usr files, /var files, and optional products
can be supplied on more than one distribution tape,
depending upon the total number of products.
Together with each distribution tape is a list of products
contained on each distribution tape.
- 2 -
Release Notes 7.1 CX/UX
2. Documentation
The following chart lists the documentation included with
the CX/UX Release 7.1 system:
___________________________________________________________
| Manual Name Pub. Number|
|____________________________________________|_____________|
| CX/UX System Administration Manual | 0890108-110|
| CX/UX Version 7.1 Release Notes | 0890108-7.1|
| CX/UX User's Guide | 0890112-030|
| CX/UX Support Tools Guide | 0890113-060|
| CX/UX Programmer's Guide | 0890114-070|
| Introducing UNIX System V | 0890184-000|
| CX Documentation Roadmap | 0890273-060|
| (KSH) KornShell Release Notes | 0890352-6.2|
| CX/UX POSIX (1003.1) Conformance Guide | 0890361-040|
| Night Hawk Documentation Overview | 0890377-010|
| GDB Documentation Set | 0890393-010|
| CX/UX Release 7.1 Readme First Instructions| 0890440-000|
| CX/UX Harris C Reference Manual | 0891019-060|
| Release 7.1 Summary Information | 0891056-000|
|____________________________________________|_____________|
Additional copies of documentation can be ordered by
contacting the Harris Software Support Center. The toll-free
number for calls within the continental United States is 1-
800-245-6453. For calls outside the continental United
States, the number is 1-305-971-6248.
Customers are encouraged to use the CX Documentation Roadmap
Manual and the Night Hawk Documentation Overview Pamphlet to
get an overview of all the Night Hawk documentation that is
available. An on-line list of manual names and
corresponding publication numbers can be obtained by using
the "man manual" command.
Hardcopy manual pages (man pages) are no longer provided.
However, man pages continue to be available as on-line
documentation. Refer to the section on manual pages in this
document for information on how you can print on-line man
pages. Selected man pages are provided in the CX/UX System
Administration Manual in the event that on-line man pages
cannot be viewed due to system problems.
Certain operating system features that are common to both
the CX/UX and the CX/RT kernels are designed to increase the
determinism and predictability of the operating system and
- 3 -
CX/UX 7.1 Release Notes
improve the process dispatch latency for high-priority
tasks. These features are described in the Real-Time
Documentation Set (0890285). They may be of interest to
real-time users who do not purchase the CX/RT product.
Users may order the Real-Time Documentation Set separately.
In general, release notes are provided with software
products. The release notes you receive will be at the
software revision level at which the associated product last
changed.
- 4 -
Release Notes 7.1 CX/UX
3. Prerequisites
Any prerequisites, if applicable, for running CX/UX Release
7.1 are described in sections 3.1 and 3.2.
3.1 Hardware Prerequisites
Any Series 4000 or Series 5000 system.
Note: Computer series written as "Series 4000-5000" refers
to all Series 4000 through Series 5000 hardware
systems or platforms.
3.2 Software Prerequisites
None.
4. Installation
4.1 Pre-Installation
The installation procedure for CX/UX Release 7.1 replaces
the current contents of your root, /usr, and /var
partitions. You should save any files currently in these
directories that you don't want lost. For example, save:
1. any files which you have modified locally,
2. files which are not distributed by Harris on the
distribution tape,
3. any files which belong to products that are not a part
of the CX/UX Release 7.1 release.
Note: Harris recommends that you back up your /, /usr, and
/var file systems using fdump(1M). You can use
either cpio(1) or tar(1) to perform the backup. The
files you save are to be restored to their original
location after the installation of CX/UX Release 7.1
is completed.
4.2 Installation Procedure
Please refer to the CX/UX System Administration Manual,
Chapter 3, for specific software installation instructions.
- 5 -
CX/UX 7.1 Release Notes
4.3 Post-Installation
After the CX/UX Release 7.1 installation procedure is
completed, proceed to:
1. selectively restore any or all of the previously saved
files.
2. merge any files which contain local modifications. You
should NOT use your locally modified CX/UX 6.2 or
earlier version of any file without merging in the
changes from CX/UX Release 7.1.
3. You should restore any files which are not distributed
by Harris. You should also restore any files belonging
to products which are not a part of the Release 7.1
release.
The setup(1M) program generates a log of products installed
on the system. The log file is located in
/usr/src/PRODUCTS/loaded. It contains the product name, the
revision level of the product, the date it was installed,
and the directory it was installed under if not /.
When optional or updated products are installed at a later
date they are appended to the log, providing a quick
reference as to which software is on the system and at what
revision level the software was installed.
Some optional products have additional installation
requirements. Please review the installation instructions
in all release notes before using setup.
4.4 Disk Partition Sizes
Each release of CX/UX includes new software in the root,
/usr, and /var partitions. Partition sizes that were
appropriate in earlier releases may not be sufficient for a
new release. Before attempting to load new software
products, the administrator should check the disk
requirements to verify that existing partition sizes are
adequate for the products that are to be installed.
CX/UX Release 7.1 kernel changes require a larger amount of
swap space than previous releases. Swap space ordinarily
comes from a set of disk partitions set aside for this
purpose. Exactly one partition must be named in the
kernel's configuration file for use during the boot process.
The remaining partitions are usually named by the swap -f
- 6 -
Release Notes 7.1 CX/UX
command that is executed by the /etc/rc script when the
system enters multi-user mode. In multi-user mode a system
should have at least as much swap space as it has primary
memory, and, in the absence of any knowledge about a
particular system's workload, Harris recommends twice as
much swap space as primary memory.
Some file systems, particularly the /var file system, grow
during daily usage. The system administrator must determine
the amount of space needed for future growth in each file
system, and then add that amount to the specified
requirements. Furthermore, the administrator should assume
that the disk space requirements will continue to increase
in future releases.
Some optional products may be installed in partitions other
than the default root, /usr, and /var partitions. Doing so,
as described below and in the product release notes, will
reduce the disk space requirements of the master pack.
4.5 Installation Cautions
4.5.1 Placement_of_the_/var_Directory
The setup(1M) command of CX/UX Release 7.1 can be directed
to put the /var directory tree in any one of three places:
1. physically within the /usr file system. Using this
option, /var is created as a symbolic link to /usr/var.
This option is most useful when re-installing CX/UX
onto an already existing master pack.
2. on a third partition (which must have been created
previously using format(1M)). When this option is
used, /var is mounted automatically during each boot.
This option is recommended when installing CX/UX onto a
new master pack.
3. on the root partition. Although the most
straightforward of the three choices, this option is
not recommended due to the root partition often being
small.
System administrators must decide where to put /var when
formatting the master disk or, at the latest, before running
setup(1M). See the CX/UX System Administration Manual,
Chapter 3, for details. Whichever file system holds the
/var directory structure must have enough free disk space
for accounting files, log files, spool files, and temporary
- 7 -
CX/UX 7.1 Release Notes
files.
4.5.2 Optional_Products_in_Alternate_Partitions
Systems with small master packs may find it impossible to
load their entire set of optional products in the default
root, /usr, and /var partitions. Certain products,
specifically the xwindows-v11 product and forthcoming
releases of NightView and NightTrace, allow for installation
in alternate partitions.
If you wish to install an optional product in an alternate
location, follow these steps:
1. Review the installation procedures described in the
release notes for the product.
2. Select or create an appropriately sized disk partition.
Partition size information is distributed with the
release tapes and may also be obtained by running the
setup command (without asking setup to load the
product).
3. Mount the partition. Harris recommends subdirectories
of /opt as convenient mount points for optional
products. For example, a partition that will be used
to hold the xwindows-v11 product might be mounted at
/opt/X11. (Remember to mount /, /usr, and /var also.)
4. Change the current directory to the directory where the
product is being installed, for example /opt/X11.
5. Use cpio to obtain the setup command from the release
tape, and run the setup command as usual.
6. Perform other installation procedures as required for
the product, as described in its release notes.
Usually, this will involve running an installation
script.
4.5.3 Latest_Release_of_Optional_Products
Although a product's release level may not have changed with
respect to what a customer is currently using, the customer
is strongly encouraged to use the latest version of the
"shipped" product's object indicated on the products
tape(s). The latest object of a given product should be
used for the following reasons:
- 8 -
Release Notes 7.1 CX/UX
o It has the latest bug fixes incorporated in it.
o It was compiled with the latest versions of the
compilers.
o It was linked with the latest versions of the system
library routines that are used by that product.
o It takes advantage of the latest system services
available in the most recent kernel.
5. Cautions
The following list summarizes the more salient points
discussed in this document. Be sure to read this entire
document to become familiar with all the notes and remarks
that apply to this new release of the CX/UX operating
system.
1. The file system structure provides only a small number
of commands in the root partition. Consequently, very
little can be done until the /usr and /var file systems
are mounted. The /sbin directory contains only those
commands that are helpful in mounting these file
systems.
2. ELF is now the default environment. (See sections 6.3
and 6.4 under ELF.)
3. The capability of creating COFF files may not be
supported in future CX/UX releases. Users should
convert their object files to ELF files. (See section
6.4 under COFF.)
4. The OCS environment should be used when linking and
building programs with 88open compatible compilers
and/or libraries. It may not be supported in future
releases. (See section 6.4 under OCS.)
5. The swap space requirement for CX/UX Release 7.1 is
larger than that for CX/UX Release 6.2. (See section
6.5 last three paragraphs.)
6. COFF programs are link-edited, by default, with the
address space starting in page 16. (See section
7.1.2.)
- 9 -
CX/UX 7.1 Release Notes
7. It is recommended that users recompile applications
that use POSIX.4 interfaces with the libraries in the
current release. (See section 7.3 and also 7.3.3.)
8. The default placement of shared memory shmat(2)
segments and usermap(2) segments in the address space
has changed in this release. (See section 7.6.7 and
7.6.9.)
9. Several routines used by device drivers were changed in
CX/UX Release 7.1. (See section 7.10.)
5.1 Kernel Builds
It is necessary to build kernels as COFF executables. If
you login as root, the SDE_TARGET environment variable is
automatically set to COFF. If, however, you su(1) to root to
build a kernel, you must set and export SDE_TARGET=COFF
before building the kernel. If you fail to do this, the
kernel will not link. To correct the problem if this
happens, do a full config(1m) and make(1) to clean up the
inappropriate files.
5.2 Future Support
Several real-time interfaces that are unique to CX/UX may no
longer be supported in the next major release. In each
case, an alternative POSIX.4 interface is available that
provides the same functionality. Applications that desire
portability to the next major release should be converted to
use the POSIX.4 interfaces.
The interfaces that may be dropped include:
o Harris asynchronous I/O:
aread(2)
awrite(2)
await(2)
acancel(2),
o Harris binary semaphores:
bsemget(2)
bsemfree(2)
bsemwait(2),
bsemwakeup(2)
lockbinsem(3C)
unlockbinsem(3C)
- 10 -
Release Notes 7.1 CX/UX
clockbinsem(3C).
6. New Features in this Release
6.1 Shared Objects and Dynamic Linking
CX/UX Release 7.1 provides shared objects and dynamic
linking. In previous CX/UX releases, programs were
statically linked. With static linking, the link editor
provides a program with all of the code and data it needs to
begin execution. With dynamic linking, only a portion of
the code and data is provided to a program by the link
editor. The remainder of the code and data that the program
requires is available through shared object files and is
dynamically linked into the program's virtual address space
during execution of the program. Dynamic linking provides
three main benefits over static linking.
o The on-disk image of the executable program is smaller,
resulting in disk space savings.
o The code in shared objects is shared among multiple
processes that use that shared object, resulting in
overall systems memory savings.
o A shared object can be updated without having to
recompile the programs that use it.
However, dynamic linking does impose a performance penalty
on running programs because of the use of position-
independent code. How severe the penalty is depends upon a
variety of factors, including the frequency of references to
shared object code, the locality of referenced routines, and
other characteristics of the program.
A new ldd(1) command lists the path names of all shared
objects that would be loaded as a result of executing a
program.
Dynamic linking is not restricted to the dynamic linker. The
system shared object libdl.so provides functions that an
application can use to dynamically link and unlink shared
objects during program execution.
For more information on dynamic linking, static linking, and
shared objects, refer to the CX/UX Support Tools Guide.
- 11 -
CX/UX 7.1 Release Notes
6.2 New Shared Objects
The file /usr/lib/libc.so.1 is the system program
interpreter for dynamically linked programs. This shared
object contains the dynamic linker and commonly used C
library routines.
The file /usr/lib/libdl.so contains user-callable functions
for dynamically linking and unlinking shared objects. The
functions are:
dlclose(3X)
dlerror(3X)
dlopen(3X)
dlsym(3X)
Refer to the man pages for more information.
6.3 ELF and DWARF File Formats
Previous CX/UX releases provided an object file format
called COFF (Common Object File Format). CX/UX Release 7.1
provides a new object file format called ELF (Executable and
Linking Format). ELF files are necessary to accomplish
dynamic linking. While SVR4 uses ELF as a replacement for
COFF, this release of CX/UX supports both object file
formats.
Like COFF files, ELF files specify the contents of object
files and provide information about sections, relocations,
and symbols. ELF files provide additional information about
segments. Core files created during the execution of ELF
programs are themselves ELF files.
Unlike COFF files, the symbol and string tables of ELF files
provide link-time information only. ELF files do not
automatically provide information needed during symbolic
debugging. To overcome this deficiency, CX/UX Release 7.1
adopts the DWARF de facto standard for symbolic debugging
information. DWARF symbolic debugging information is placed
into ELF files when compilation is done with the appropriate
option (e.g., -g for the C compiler). The gdb(1) and
NightView(1) debuggers use DWARF information in their
debugging activities. To hide the low-level details of
DWARF from the programmer, a new interface library
/usr/lib/libdwarf.a is provided.
- 12 -
Release Notes 7.1 CX/UX
Just as the libld.a system library provides a user-level
interface to functions which access COFF files, so a new
libelf.a system library can be used to access ELF files.
ELF and COFF files, in general, are not compatible. Tools
that understand and depend upon the format provided in COFF
will require revision if they are to understand and depend
upon the format provided in ELF. Many UNIXO systems do not
support the mixing of ELF and COFF files in an application.
To effect a smooth transition from COFF to ELF, however,
this release of CX/UX provides limited facilities and
mechanisms for accepting both COFF and ELF files in the
development of an application.
Some system processors, such as ld(1), internally convert
COFF object into ELF object while they are executing. A
cof2elf(1) tool can be used to permanently convert a COFF
file into an ELF file. The use of both COFF and ELF files
in a development setting should be restricted to a
transitional mode while converting an application that uses
COFF files into one that uses ELF files. It is recommended
that object files be permanently converted from COFF to ELF
by recompiling them in the ELF software development
environment (discussed in the following section).
Facilities for converting from ELF to COFF are not
available.
For more information on ELF, DWARF, and COFF, refer to the
CX/UX Support Tools Guide.
NOTE: The capability of creating COFF files may not be
supported in future CX/UX releases. Users should convert
their object files to ELF files.
6.4 Software Development Environments
The construction of a software application or piece of code
requires, at the minimum, compilation of the code. Usually,
debugging and other analysis are done on the software and
resulting object files as they evolve into their final
state. Many factors contribute to the software development
environment, including the base operating system, the object
file format, and compliance with industry standards. The
user must select an environment in which to operate.
This release of CX/UX provides three development
environments.
- 13 -
CX/UX 7.1 Release Notes
COFF This is an older environment, maintained for
compatibility with previous releases of CX/UX.
Compilation systems, debuggers, and object file
tools operate on COFF object files. Some
features typically associated with SVR4, such
as shared libraries and DWARF, are not
available in this environment. The Berkeley
universe is supported, however. The COFF
environment may not be supported in future
releases. Users should convert to the ELF
environment.
OCS This is a variation of the COFF environment
which provides compliance with 88open's BCS
(Binary Compatibility Standards) and OCS
(Object Compatibility Standards).
The OCS environment should be used when linking
and building programs with 88open compatible
compilers and/or libraries. It, too, may not
be supported in future releases.
ELF This is the default environment. Compilation
systems, debuggers, and object file tools
operate on ELF object files. Shared libraries,
dynamic linking, and DWARF symbolic debugging
information are integral parts of this
environment. As much as possible, the
semantics and functionalities of the
compilation systems and tools available in the
COFF environment (discussed next) are preserved
in the ELF environment. Notable exceptions
include the following:
1. The Berkeley universe, which Harris has
provided in the past, is not supported in
the ELF environment.
2. The following options to as(1) have
meaning in the COFF environment but not in
the ELF environment. They are accepted
but ignored by the assembler in the ELF
environment.
-r
-Qfile_buffer_limit=number
- 14 -
Release Notes 7.1 CX/UX
-Qno_parse_errors
-QOCS
-Tsymtab_size
3. The following options to ld(1) have
meaning in the COFF environment but not in
the ELF environment. They are accepted
but ignored by the link editor in the ELF
environment.
-f fill
-ocs
-Qfile_buffer_limit=number
-QOCS
-VS num
The -M option to ld(1) has different semantics in the two
environments. In the ELF environment, it is followed by the
name of a mapfile. In the COFF environment, it causes a
message to be output for multiply defined external
definitions.
In the ELF environment, the link editor internally converts
COFF files to ELF files. By default, the link editor
performs the conversion without notification. However, if
the -v option to ld(1) is used, notification is given of
every file that is converted in this manner.
In the ELF environment, both dynamic linking (which uses
shared libraries) and static linking (which uses static, or
archive, libraries) are available. Dynamic linking offers
the advantages of reduced disk image sizes for programs,
reduced memory usage when multiple processes share the code
from a shared object, and reduced link edit time in a
development environment.
However, the use of shared libraries can impose a
performance penalty on the overall execution time of a
program. By default, programs built under CX/UX Release 7.1
use static linking. The standard profile and login files
provided with CX/UX Release 7.1 set the STATIC_LINK
environment variable, which directs the compilation systems
to use static linking.
- 15 -
CX/UX 7.1 Release Notes
A user may select dynamic linking either by unsetting
STATIC_LINK or by using certain compilation system options
(e.g., -ZLINK=dynamic with the C and the Fortran compilers).
The use of these options overrides the specification made by
the presence or absence of STATIC_LINK.
Compilation, debugging, and examination of object files in a
particular development environment is accomplished by
setting the SDE_TARGET variable to one of the three
following strings.
ELF For the ELF environment.
COFF For the COFF environment.
OCS For the OCS environment.
If SDE_TARGET is not set, the ELF environment is used. Some
tools provide options which directly specify the development
environment to be used during the execution of that tool.
The development environment has no direct effect on the
execution of a program. Unless a program examines and
relies upon this variable, the setting of SDE_TARGET is
irrelevant during execution of the program.
Previous CX/UX releases offered only COFF as the default
environment and OCS as the alternative environment. This
release of CX/UX provides ELF as the default environment.
Thus, the simple command:
cc foo.c
produces, by default, an ELF program. If STATIC_LINK is set
(which is the default case provided by CX/UX), this program
is statically linked with the archive C library. If
STATIC_LINK is not set, the program dynamically links the
shared object portion of the shared C library.
NOTE: The COFF and the OCS environments may not be
supported in future CX/UX releases. Users should convert to
the ELF environment.
Each development environment has a subdirectory under
/usr/sde which contains tools and libraries specific to that
environment. For example, /usr/sde/elf/usr/lib/libc.a is
the ELF version of the C library used in static linking.
- 16 -
Release Notes 7.1 CX/UX
For libraries having both an ELF and a COFF version, the
standard system name of the library is a link to the ELF
version. For example, /lib/libm.a is a symbolic link to
/usr/sde/elf/usr/lib/libm.a, making it the ELF version of
the math library used in static linking.
Comparison of COFF, OCS, and ELF Environments
_____________________________________________________________________________________
| Environmental Feature COFF OCS ELF & DWARF |
|____________________________________________________________________________________|
| |
| SDE_TARGET variable set to COFF OCS ELF (default) |
| |
| Berkley Universe Supported Yes No No |
| |
| Static Vs Dynamic Linking Static Static Both (static is default) |
| |
| Shared Libraries No No C, math, malloc, X11, POSIX, Fortran|
| |
| POSIX.4 support Yes Yes Yes |
| |
| 88open Compliance (BCS) Yes Yes No |
| |
| 88open Compliance (OCS) No Yes No |
|____________________________________________________________________________________|
For tools having both an ELF and a COFF version, the
standard system name of the tool refers to a driver that
determines which version to invoke, based upon the
development environment and/or the format of object files
read by the tool. For example, /bin/as invokes
/usr/sde/elf/usr/bin/as in the ELF environment and
/usr/sde/coff/usr/bin/as in the COFF environment.
For more information on software development environments
refer to the CX/UX Programmer's Guide, and CX/UX Support
Tools Guide.
6.5 SVR4 Memory Management
Previous releases of the CX/UX operating system contained a
memory manager based on SVR3. The memory manager in CX/UX
Release 7.1 is based on SVR4. The SVR4 memory manager has
several important new capabilities. Chief among these are
page-based control of the address space, memory-mapped
files, and a large disk cache.
- 17 -
CX/UX 7.1 Release Notes
The SVR4 memory manager views the address space of a process
as a simple vector of pages. Each page in the address space
can be manipulated independently of the other pages. Each
page can be mapped to a different object or be unmapped, can
be locked into primary memory or be unlocked, can have
different access rights, and so on. Now applications have
much more control of their address spaces compared with
previous releases.
The SVR4 memory manager allows a process to map a file into
its address space. A memory-mapped file can be accessed
directly through the CPU's load and store instructions
instead of indirectly through the read(2) and write(2)
system calls. As a file access method, memory mapping has
the advantage of greater simplicity (single-level store
programming model) and greater efficiency (no need to copy
file data between operating system and application buffers).
Previous releases of the operating system maintained two
disk caches: the buffer cache under the control of the file
system and the page cache under the control of the memory
manager. This release merges the two caches into one cache
under the control of the memory manager. The net result
should be a larger and more effective disk cache.
The new interfaces to the SVR4 memory manager include the
following routines: mincore(2), munmap(2), memcntl(2),
mmap(2), mprotect(2), swapctl(2), mlock(3C), munlock(3C),
mlockall(3C), munlockall(3C), and msync(3C). The older SVR3
interfaces, such as brk(2), sbrk(2), shmat(2), and plock(2),
are also available. And finally, Harris-unique enhancements
to the memory manager added in previous releases are still
available. These include support for local memory,
userdma(2), usermap(2), shmbind(2), and memadvise(2). The
following paragraphs discuss the impact of the new memory
manager on these interfaces.
Applications can no longer choose the cache modes for their
data and and stack segments; copyback mode is always used.
For backwards compatibility, the memadvise(2) system call
silently ignores attempts to set the cache mode. Shared
memory segments that are bound to physical memory via the
shmbind(2) service use a cache mode that is appropriate for
the physical address range. For example, I/O space is cache
inhibited, and the cache mode for reserved sections of
primary memory is determined by the reserve statement in the
kernel's configuration file. The default cache mode for
regular shared memory segments is copyback.
- 18 -
Release Notes 7.1 CX/UX
Series 4000 data caches are not coherent with DMA transfers.
Therefore, the operating system issues data cache flush
operations either before or after most I/O requests. These
operations can have an impact on interrupt and context
switch latency. The lowest-numbered CPU on each CPU board
fields all of the cross-CPU interrupts issued for the
purposes of cache flushing. Developers of real-time
applications may want to consider the fact that the
remaining CPUs on each board will not receive these
interrupts.
In previous releases, memadvise(2) controlled how the text,
data, and stack segments and the U-block used local memory.
In this release, the data segment and stack segment
categories have been replaced by writable data and read-only
data categories. The memadvise(2) service still accepts the
data segment and stack segment categories, but they are
treated as aliases for the writable data category.
Furthermore, the text segment category includes all pages
that have execute access, wherever they may be in the
address space.
A local memory usage policy can be specified in the mmap(2)
system call.
Kernel text can be replicated in selected local memory pools
with the ktextlocal parameter in the kernel's configuration
file, but a copy of the kernel remains in global memory.
In previous releases, there was one page replacement daemon
for every CPU, and page replacement was triggered only by
the state of the global memory pool. In this release, there
is only one page replacement daemon in the system, and page
replacement occurs in each memory pool independently of the
states of the other memory pools.
The swap space requirement for this release is larger than
that for CX/UX 6.2. In CX/UX 6.2, the system's capacity for
storing anonymous pages (pages used for a process' stack,
heap, and shared memory segments) is the size of primary
memory plus the size of all of the swap areas. Because of
this, the 6.2 kernel will boot and run without any swap
space at all. In this release, the system's capacity for
storing anonymous pages is only the size of all of the swap
areas.
Consequently, the Release 7.1 kernel needs swap space to
simply boot. The larger swap space requirement is a
property of the design of the SVR4 memory manager. In CX/UX
- 19 -
CX/UX 7.1 Release Notes
Release 7.1, the sum of the sizes of all of the swap areas
should be at least as large as primary memory. Exactly one
swap area must be specified in the kernel's configuration
file; the remaining swap areas should be added during the
transition to multi-user mode with the swap(1) command. In
the absence of any knowledge about a particular system's
workload, Harris recommends twice as much swap space as
primary memory.
For more information on these topics, see the related man
pages, memory(7), cache(7), the CX/UX Programmer's Guide,
and the CX/UX System Administration Manual.
6.6 POSIX.4
The IEEE Draft Standard P1003.4/D14 is now an accepted
standard, which is known as IEEE Standard 1003.1-1993. The
POSIX.4 interfaces are organized as an extension to the
original POSIX.1 standard and will be published as one
entity. CX/UX Release 7.1 supports all functional areas as
specified by this new standard. Note that computer vendors
cannot claim compliance to this standard because currently
there is no test suite to verify compliance.
Applications that were written for previous CX/UX releases,
which supported other drafts of the POSIX.4 interfaces,
might need modification to operate under this release.
Please see the section entitled Changes from Previous
Releases for specific details on which POSIX.4 interfaces
have changed to support the final version of this standard.
The POSIX.4 interfaces are documented in the Real-Time
Documentation Set, CX/UX Programmer's Guide, and man pages.
Following is a list of all of the POSIX.4 functional areas
and the name of the chapter and manual in which the
corresponding CX/UX interfaces are documented:
- 20 -
Release Notes 7.1 CX/UX
Counting semaphores "Interprocess Synchronization"
CX/UX Programmer's Guide
Process memory locking "Memory Management"
CX/UX Programmer's Guide
Memory mapped files and shared memory "Memory Management"
CX/UX Programmer's Guide
Priority scheduling "Process Scheduling and Management"
Real-Time Documentation Set
Real-time signal extension "Signal Management"
CX/UX Programmer's Guide
Clocks and timers "Timing Facilities"
CX/UX Programmer's Guide
Interprocess message passing "Interprocess Communication"
CX/UX Programmer's Guide
Synchronized input and output "Real-Time Files"
CX/UX Programmer's Guide
Asynchronous input and output "Real-Time I/O"
CX/UX Programmer's Guide
6.7 STREAMS Link Level Driver
This release includes a STREAMS access to LAN drivers
through the Data Link Provider Interface (DLPI). The dlpi(7)
man page describes the DLPI interface, and the sld(7) man
page describes the STREAMS LAN Driver (SLD).
6.8 New Libraries
Several of the system libraries are available in both ELF
and COFF versions. These include the C, math, X11, POSIX,
Fortran, and malloc libraries. The ELF versions are also
available in two forms - one for static linking and one for
dynamic linking. The compilation system uses either the
static version or the shared version, depending on the
software development environment being used and the options
specified in the compilation system.
The library /usr/lib/libelf.a provides a user interface to
functions which access an ELF file. The available functions
are:
- 21 -
CX/UX 7.1 Release Notes
elf_begin(3E) elf_getphdr(3E)
elf_cntl(3E) elf_getscn(3E)
elf_end(3E) elf_getshdr(3E)
elf_error(3E) elf_hash(3E)
elf_fill(3E) elf_kind(3E)
elf_flag(3E) elf_next(3E)
elf_fsize(3E) elf_rand(3E)
elf_getarhdr(3E) elf_rawfile(3E)
elf_getarsym(3E) elf_strptr(3E)
elf_getbase(3E) elf_update(3E)
elf_getdata(3E) elf_version(3E)
elf_getehdr(3E) elf_xlate(3E)
elf_getident(3E)
Note: This library has been designed to fully exploit
available memory resources when it is used to open
and read ELF files. Because the library is used in
several compilation systems tools, such as, the link
editor and the assembler, users may observe greater
memory consumption when building ELF programs than
when building COFF programs.
7. Changes from Previous Releases
7.1 Compilation Systems
7.1.1 C_Library
The nlist(3C) function accepts the name of either an ELF
executable file or a COFF executable file. Symbol tables in
COFF files are different from symbol tables in ELF files,
both in format and in the meaning of some of the fields.
The name list structure defined in /usr/include/sys/nlist.h
is the one traditionally associated with COFF files. If the
specified executable file is an ELF file, the COFF-style
name-list structure receives values from corresponding
fields in the ELF symbol table. No semantic conversion of
fields from the ELF meaning to the corresponding COFF
interpretation is performed. Programs invoking this
function must be aware of the object file format of the
specified executable file and perform appropriate semantic
interpretation of the name list.
- 22 -
Release Notes 7.1 CX/UX
7.1.2 Link_Editor
In CX/UX Release 7.1, COFF programs are link-edited, by
default, with the address space starting in page 16. This
suppresses a page 0 from the address space of the running
process, causing the process to receive a signal if it
attempts to dereference a NULL pointer. Even though
dereferencing a NULL pointer is indicative of a programming
error, some programs rely on this behavior. Kernel and
link-editor facilities, therefore, are provided to permit
these programs to continue dereferencing a NULL pointer.
If a process has its address space beginning above page 0
and that process dereferences a NULL pointer, the kernel
will normally supply the process with a page of zeroes
starting at address 0x0. This provision is made at the time
the dereference is attempted, and the dereference will not
produce a signal. If a signal is desired, however, then the
COFF link editor should be invoked with the -zno_page_zero
option, which marks the vendor section of the program to
instruct the kernel not to provide the page of zeroes.
COFF programs which need to have the address space starting
in page zero should be link-edited with the the -zzeroword
option. In this case, the process incurs a small
performance penalty on startup, and the kernel provides the
process with a word of zeroes at address zero.
ELF programs are link-edited, by default, without a page
zero in the address space. The -z lowzeroes option to the
ELF link editor instructs the kernel to provide a page of
zeroes, at address 0x0, when the process starts up.
A new -Qfpcr= option is added to ld. This option takes a
numerical argument which is to become the value of the
floating-point control register (fpcr) at program startup.
Appropriate fields in the vendor section are modified to
effect this setting of the fpcr. Use of this option effects
an override of the default setting of the fpcr at program
startup.
7.1.3 Analyze88
The analyze88 tool provides the same functionality for a
statically-linked ELF program as it does for a COFF program.
For a dynamically-linked ELF program, analyze88 operates
only on the static portion of the program. The provision of
analyze88 functionality and transformation of shared objects
is neither feasible nor advantageous.
- 23 -
CX/UX 7.1 Release Notes
When analyze88 is used to profile COFF programs, it utilizes
the region of the program's address space between the .text
section and the .data section as a "patch area." When
analyze88 is used to profile ELF programs, it uses a
separate .analyze_patch section in the program file as the
"patch area." Usually, the size of the provided patch area
is sufficient for analyze88. (For ELF programs the default
size of the patch area is three times the size of the
program's .text section.) In rare cases, where the size is
insufficient, analyze88 alerts the user to recreate the
program with a larger patch area. For COFF programs, the
patch area can be enlarged by relinking the program with the
use of a linker command file. ELF programs can be relinked
using the link editor's -Qanalyze_patch_size= option to
reserve additional space. (This option can also be used to
reduce the size of the patch area.)
7.2 System Daemons
The page replacement daemon is now called pageout instead of
vhand, and there is only one such daemon in the system
rather than one per CPU.
mbdaemon is a new kernel daemon that manages network buffer
space.
fsflush is a new kernel daemon that periodically flushes
dirty file system pages to backing store.
Parameters in the kernel's configuration file control the
operation of all these daemons. For more information, see
the CX/UX System Administration Manual.
7.3 POSIX.4 Interfaces
POSIX.4 interfaces that were released in previous CX/UX
releases have been based on various IEEE Draft Standards.
CX/UX Release 7.1 supports POSIX.4 interfaces that are
specified in the final version of this standard, IEEE
Standard 1003.1-1993. Some of the changes that have been
made to update the POSIX.4 functional areas to support this
standard will cause source incompatibility for existing
programs that are based on previous releases of the POSIX.4
interfaces. It is recommended that all applications that
utilize any of the POSIX.4 interfaces be recompiled with the
new release. Compilation errors will indicate most areas
where source incompatibility exists. Recompilation will
also update the application so that it is using the most
up-to-date POSIX.4 library routines, some of which contain
- 24 -
Release Notes 7.1 CX/UX
performance improvements in this release.
The sections below document the changes that must be made to
source code that utilizes the POSIX.4 interfaces that have
been released in previous CX/UX releases. The changes
required in an application that utilizes POSIX.4 interfaces
depends upon the operating system release for which the
application was originally written. The changes required
are documented below according to the release to which the
user is upgrading. The changes required are cumulative; for
example, if the source code was originally developed under
release 6.1, then the changes made in releases 6.2 and 7.1
must all be applied to the application source code.
Note: You need to concern yourself with the following
sections on Release 6.2 and Release 7.1 changes only
if you have existing programs that use POSIX.4
interfaces from previous releases.
7.3.1 CX/UX Release 6.2 Changes Affecting Existing
Applications
7.3.1.1 Binary semaphores
Support for POSIX.4 binary semaphore interfaces has been
dropped. This functionality is now supplied by the counting
semaphore interfaces.
7.3.1.2 Clocks and Timers
The name of the header file that must be included by a
program that uses any of the POSIX.4 clocks and timers
interfaces has changed. Previously the name of this include
file was ; the name of the header file is now
.
7.3.2 CX/UX Release 7.1 Changes Affecting Existing
Applications
7.3.2.1 Counting Semaphores
The counting semaphore functional area has changed
extensively. Programs that use these interfaces will need
to be upgraded to be functional under the new release. An
overview of the changes follows.
Several of the counting semaphore interfaces have changed
names. sem_lock is now called sem_wait. sem_trylock is now
called sem_trywait. sem_unlock is now called sem_post.
- 25 -
CX/UX 7.1 Release Notes
The functionality of the sem_init function has been split
into two separate functions. sem_init is now used only to
initialize an "unamed" counting semaphore that already
exists in memory. To use this interface, the application
must allocate space for a counting semaphore in a shared
memory region and then initialize that semphore by calling
sem_init. sem_open is a new function that is used to obtain
a "named" counting semaphore from the system (this
functionality was previously provided by the sem_init
function). This interface is used when the application
wants the system to allocate space for the counting
semaphore. All processes that call sem_open with the same
name will be referencing the same semaphore.
The sem_destroy function should be called only for
destroying unnamed semaphores. A new function, sem_close,
is used for destroying named semaphores. This means an
application either uses the sem_init and sem_destroy pair or
the sem_open and sem_close pair for creating and destroying
attachments to counting semaphores.
7.3.2.2 Real-Time Signals
The interface that blocks until a signal is received is now
called sigwaitinfo instead of sigwaitrt.
The sigevent structure contains a new member, sigev_notify,
which indicates whether a signal should really be sent.
This field must be set to the value SIGEV_SIGNAL if a signal
is to be generated. This change affects several other
interfaces that utilize the sigevent structure and are
described in subsequent sections.
Warning: Any program that uses a sigevent structure to
specify that a signal is to be delivered when an
event of interest occurs must now initialize the
sigev_notify member to SIGEV_SIGNAL. Failure to
do this initialization will not cause a
compilation error but may cause no signal to be
delivered.
When a signal handler is invoked such that a siginfo_t
structure is delivered and the signal was sent by a user
process via an interface such as the kill system call, the
si_code member of the signinfo_t structure is now called
SI_USER instead of SI_KILL.
- 26 -
Release Notes 7.1 CX/UX
7.3.2.3 Synchronized I/O
Setting the O_DSYNC and O_SYNC flags no longer affects read
operations to the file. These flags now specify
synchronized I/O data intergity or synchronized I/O file
integrity, respectively, for write operations. Read
operations can be synchonized to the same level of integrity
as write operations by specifying the O_RSYNC flag in
conjunction with either O_DSYNC or O_SYNC.
7.3.2.4 Asynchronous I/O
The aiocb structure contains a sigevent structure to define
how the calling process will be notified upon I/O
completion. When submitting an asynchronous I/O request via
aio_read, aio_write, lio_listio, or aio_fsync, the
sigev_notify member of this structure must be initialized as
described in the real-time signals section above.
7.3.2.5 Clocks and Timers
The typedef for a POSIX.4 clock ID has changed names. This
typedef was previously named clock_t and is now named
clockid_t.
The timer_create interface specifies a pointer to a sigevent
structure that defines how the calling process will be
notified upon timer expiration. The sigev_notify member of
this structure must be initialized as described in the
real-time signals section above.
The timer_create() function no longer returns the timer ID.
Instead, this function returns a zero for success and a -1
if an error has occurred. The timer ID is returned to the
location pointed to by a new argument to the timer_create()
function.
The behavior of the nanosleep() function has changed for the
case in which the sleep is interrupted by a signal. When
nanosleep() is interrupted by a signal, it returns -1 with
errno set to EINTR. If the second argument to nanosleep()
is non-null, then it points to a timespec structure that is
filled with the time remaining in the original sleep
interval.
- 27 -
CX/UX 7.1 Release Notes
7.3.2.6 Interprocess Message Passing
The mq_destroy() function is now called mq_unlink().
The mq_getattr() and mq_setattr() functions reference the
mq_attr structure. This structure no longer contains the
elements mq_sendwait and mq_rcvwait.
When a notification request is attached to a message queue
via mq_notify and the notification is delivered to that
process, then the notification request is now detached for
this process, and the message queue is once again available
for any process to attach a notification request.
Previously an attached notification request was not detached
unless the process explicitly detached the notification
request via mq_notify.
The mq_notify interface specifies a pointer to a sigevent
structure that defines how the calling process will be
notified when a message queue becomes non-empty. The
sigev_notify member of this structure must be initialized as
described in the real-time signals section above.
7.3.2.7 Memory Mapped Files and Shared Memory
In previous releases, the locks that were placed on pages by
using mlock were nested; that is, if mlock was called twice
for a given address range, then it was necessary to call
munlock twice for this address range to unlock the pages.
In the current release, calls to mlock are not nested, and
munlock needs to be called only once to unlock a given
address range.
7.3.2.8 Real-Time Files
The real-time files interfaces have been removed from IEEE
Standard 1003.1-1993. These interfaces are no longer
supported by CX/UX. The interfaces that have been removed
include the following: rf_create, rt_getattr, rf_setattr,
rf_getalloccap, rf_getcachecap, rf_getbiocap, rf_getaiocap,
rf_getdiocap, rf_getallocincr, rf_getincr, rf_getbuf, and
rf_freebuf.
7.3.3 Other_Changes
Some of the changes that have been made to update the
POSIX.4 functional areas to support the final version of the
POSIX standard will not cause source incompatibility for
existing programs that are based on previous versions of the
- 28 -
Release Notes 7.1 CX/UX
related interfaces. The sections that follow describe
changes to the interfaces that will not require source
changes in applications that were built to use previous
versions.
It is recommended that users recompile applications that use
POSIX.4 interfaces with the libraries in the current
release. If any cooperating programs are recompiled under
the new release, then all of the cooperating programs must
be recompiled. For example, a program compiled with the
version 7.1 POSIX.4 library that uses shared memory will not
be able to communicate with a program which uses the shared
memory interfaces provided by an earlier operating system
release.
7.3.3.1 Memory Mapped Files and Shared Memory
Full support is now provided for memory mapped files. The
previous release of these interfaces contained many
restrictions that are not a part of the IEEE Standard
1003.1-1993. These interfaces are now fully supported as
defined in the standard. Removal of the previous
restrictions does not affect applications that were written
to adhere to the restrictions imposed by the previous
release. Most of these interfaces are now a part of libc
instead of libposix4. See the following man pages for full
details: mmap(2), munmap(2), mlockall(3C), munlockall(3C),
mlock(3C), munlock(3C), shm_open(3P4), and shm_unlink(3P4).
The mprotect(2) and msync(3C) functions are now supported.
7.3.3.2 Interprocess Message Passing
The mq_setattr() function is now supported. It allows the
user to set the message queue to operate in non-blocking
mode.
7.3.3.3 Clocks and Timers
If no pointer to a sigevent structure is provided on a call
to timer_create(), then upon expiration of the timer, the
SIGALRM signal is sent to the process. If the SIGALRM
signal is being caught and the SA_SIGINFO flag is set for
the SIGALRM signal, then the value delivered with the signal
will be the timer ID of the expired timer.
- 29 -
CX/UX 7.1 Release Notes
7.3.3.4 Asynchronous I/O
Null elements can now be included in the array of I/O
requests that are passed via the lio_listio() function.
These elements will be ignored.
7.3.3.5 Counting Semaphores
A new function, sem_getvalue, has been added to obtain the
current value of a counting semaphore.
7.4 Core Files
A core image file created by the operating system when a
process terminates abnormally is now named core.pid where
pid is the process's ID. For backwards compatibility, core
is a hard-link to the most recently created core.pid file.
7.5 Utilities
7.5.1 /etc/rc
The rc script has been changed slightly. Three log files
are now saved at boot time, and compressed using
compress(1). The log files which are saved are:
/var/adm/sulog, /usr/lib/X11/xdm/xdm-errors, and
/var/cron/log. These are saved in their respective
directories by appending .OLD to the filename. If you need
to view these saved log files, you must first uncompress(1)
them. See the uncompress(1) man page for more information.
7.5.2 fdump(1)
There is a new option in the fdump(1) command, -M, which
allows you to specify the tape size in megabytes. See the
fdump(1) man page for more information.
7.5.3 tar(1)
The tar(1) utility now creates absolute pathnames if they
don't exist.
7.5.4 mkdir(1)
The mkdir(1) command can now be accessed from /sbin and from
/usr/bin.
- 30 -
Release Notes 7.1 CX/UX
7.5.5 man(1)
The man(1) script can now search different paths. You can
specify the paths to search in the environment variable
MANPATH, or use the -Mpath command-line option. Multiple
paths may be specified, separated by colons (i.e.
-M/usr/catman/a_man:/usr/catman/p_man). In addition, man(1)
will now format any unformatted man pages found. See the
man(1) man page for more information.
7.5.6 login(1)
The login(1) program now has additional configuration
options. The system administrator can configure different
timeout and security features. See the login(1) man page
for more information.
7.5.7 vmstat(1)
The output of the vmstat(1) command was changed to be
meaningful for the new SVR4 memory manager.
7.5.8 mpstat(1)
mpstat(1) now displays information about memory pool usage.
7.5.9 pstat(1)
The pstat(1) command no longer displays the region table or
the swap table.
7.5.10 ps(1)
The output of the ps(1) command is identical to that
produced by SVR4. Like SVR4, the -n option is no longer
supported, and the -c option now shows scheduling class
information.
7.5.11 top(1)
This release contains top(1) version 3.0. The version 3.0
display is very similar but not identical to earlier
versions.
- 31 -
CX/UX 7.1 Release Notes
7.5.12 swapon(1m)
The 4.2BSD swapon(1m) command was dropped in favor of the
SVR4 swap(1m) command.
7.5.13 swap(1m)
A new option, -f, in the SVR4 swap(1m) command reads
/etc/fstab and activates all of the swap devices found
therein.
7.5.14 ipcs(1)
The -b option now prints memory binding information for
shared memory segments.
7.5.15 Message_Catalogs_in_Utilities
The following commands use message catalogs to obtain
internationalized text strings for error and informational
messages.
cat chgrp chmod chown cp
date diff file find grep
ln ls mkdir more mv
passwd rm rmdir su tar
American English messages are displayed by default. Message
catalog files for other languages can be created by
translating the source catalog files in the directory
/usr/lib/locale/src/LC_MESSAGES. Once translated, use the
gencat(1M) command to create each compiled catalog file and
install it as described in the gencat(1M) man page.
7.6 System Services
7.6.1 fork(2)
fork(2) no longer assigns process IDs sequentially.
7.6.2 exec(2)
exec(2) can now load both ELF and COFF executables.
- 32 -
Release Notes 7.1 CX/UX
7.6.3 badaddr(2)
The address being tested no longer needs to be locked in
memory.
7.6.4 shmget(2)
The default cache mode for shared memory segments not bound
to the physical address space via shmbind(2) is copyback.
Attempts to specify a cache mode other than copyback are
silently ignored.
7.6.5 shmbind(2)
Bound shared memory segments use a cache mode that is
appropriate for the specified physical address. For
example, I/O space is cache inhibited. Reserved sections of
primary memory have a cache mode that is determined by the
reserve statement in the kernel's configuration file.
7.6.6 shmctl(2)
A new command, SHM_RMIDLD, destroys both the shared memory
segment ID and the shared memory segment itself at the same
time: when the segment is no longer in use. (By contrast,
the standard IPC_RMID command destroys the shared memory
segment ID immediately and destroys the shared memory
segment itself when it is no longer in use.)
7.6.7 shmat(2)
By default, the kernel places shared memory segments in the
virtual address range 0x80000000 to 0xfffff000. This policy
complies with both the BCS and the ABI. If insufficient
space is available, shmat(2) returns -1 and errno is set to
ENOMEM. Please note that, shmat() failures are identified
by the value -1; other "negative" values are NOT failures.
7.6.8 userdma(2)
userdma(2) uses the same locking mechanism as memcntl(2) and
plock(2). A given page can be locked multiple times through
different mappings; however, within a given mapping, page
locks do not nest. All multiple-lock operations on the same
address and in the same process are removed with a single
unlock operation.
A locked buffer is implicitly unlocked if the mapping is
removed or a page is deleted through file removal or
- 33 -
CX/UX 7.1 Release Notes
truncation.
The physical location of a locked buffer can change if the
process invokes fork(2).
The physical location of a locked buffer can change if a
private, read-only mapping is made writable by mprotect(2).
The physical location of a locked buffer can change if the
buffer resides in a local memory pool, is mapped to a file,
and another process attempts to access the file.
The physical location of a locked buffer can change if the
buffer resides in a local memory pool and the process
migrates to a CPU not attached to that pool (see
memadvise(2) and mpadvise(2)). This form of migration only
occurs in mpadvise(2) at the application's request; the
operating system's load balancer never migrates a process
out of a local memory pool.
7.6.9 usermap(2)
usermap(2) no longer requires the object mapped by the
target address to be locked in memory, and no longer
requires that the length be less than or equal to 8.
The kernel places usermap(2) segments in the virtual address
range 0x80000000 to 0xfffff000. This policy complies with
both the BCS and the ABI. If insufficient space is
available, usermap(2) returns -1 and errno is set to ENOMEM.
Please note that usermap() failures are identified by the
value -1 -- other "negative" values are NOT failures.
7.6.10 memadvise(2)
Applications can no longer select a cache mode for their
data and stack segments. Attempts to do so are silently
ignored. userdma(2) should be used to make an I/O buffer
coherent with DMA.
In previous releases, memadvise(2) controlled how the text,
data, and stack segments and the U-block used local memory.
In this release, the data segment and stack segment
categories have been replaced by writable data and read-only
data categories. The memadvise(2) service still accepts the
data segment and stack segment categories, but they are
treated as aliases for the writable data category.
Furthermore, the text segment category includes all pages
that have execute access, wherever they may be in the
- 34 -
Release Notes 7.1 CX/UX
address space.
7.6.11 iconnect(2)
The iconnect(2) system call no longer makes a copy of the
calling process's text segment when the IC_DEBUG flag in the
ic_flags field of the icon_conn structure is set. This
means that breakpoints set via the console will be visible
to other processes running the same program. If a process
encounters a console breakpoint while it is executing in
user mode, the process will be terminated with a SIGTRAP
signal. If it is likely that a user-mode process will
execute a routine that is being debugged via the console,
the tester can avoid the SIGTRAP signals by:
1. Temporarily creating a duplicate of the executable
file, or
2. Temporarily changing the routine under test so that it
is not executed in user mode.
7.6.12 ienable(2)
Data cache coherence becomes an issue when a process uses
local memory and connects to an interrupt. The iconnect(2)
and ienable(2) system calls place the burden of data cache
coherence on their callers. Unlike previous releases, these
system calls no longer attempt to keep the caches coherent.
The issue is this: translations to local and global page
frames usually specify the copyback or writethrough cache
modes. In order to keep the data caches coherent,
translations to remote page frames must specify the cache-
inhibited cache mode. The terms local and remote describe a
relationship between a page frame and a CPU. The kernel
builds translations for a process with respect to the CPU on
which the process is running. If translations were built
with respect to one CPU and subsequently used on a different
CPU, the data caches could become corrupted. In most
circumstances, these issues are hidden from applications by
the kernel's load-balancing and process-migration
algorithms. However, the situation just described can occur
if a process running on CPU A has bindings to local memory
and connects to an interrupt serviced by CPU B.
Applications should follow this procedure - the same
procedure recommended by previous releases - when connecting
to interrupts:
- 35 -
CX/UX 7.1 Release Notes
1. Discover which CPU services the interrupt of interest.
2. Bind the application to the CPU servicing the
interrupt.
3. Attach to any shared memory segments, mmap(2) any
files, etc. Lock all pages to be referenced at
interrupt level into memory.
4. Connect to the interrupt.
ienable(2) no longer returns an error if the process is
attached to a shared memory segment that is bound to local
memory.
7.7 curses
A problem involving the use of Ctrl-Z with a curses
application has been corrected. The talk(1C) program, for
example, now behaves correctly.
7.8 Manual Pages
Manual pages are no longer provided in hard-copy form.
Manual pages, however, continue to be available as on-line
documentation. Manual pages that are available on line are
contained in the following on-line reference manuals:
1. CX/UX User's Reference Manual
2. CX/UX Programmer's Reference Manual
3. CX/UX Administrator's Reference Manual
The manual pages in each of these manuals are presented in
sections; for example, the general purpose commands that are
described throughout the ensuing pages of this guide are
contained in Section 1 of the on-line CX/UX User's Reference
Manual, and the commands related to certain types of system
maintenance procedures performed by your system
administrator are contained in Section 8 of the on-line
CX/UX Administrator's Reference Manual. When you enter the
man command to display a manual page, you can optionally
specify the section by entering the command as indicated in
the following example:
man 1 clear
This capability is especially useful when a command is
- 36 -
Release Notes 7.1 CX/UX
documented in more than one section. If you do not specify
a section number, the documentation contained in all
sections is displayed.
Note: References to manual pages in this guide will
include notation of the appropriate section as
illustrated by the following:
man(1)
For additional information on use of the man(1) command,
refer to the system manual page.
Printing On-line Manual Pages
To print a manual page, enter the command as shown in the
following example.
man clear | lp ( or man 1 clear to specify section number )
For additional information on use of the man(1) command,
refer to the system manual page.
7.9 Kernel Configuration File
The following parameters in a kernel configuration file are
no longer supported: gpgslo, gpgshi, vhndfrac, vhandl,
vhandr, maxumem, and sptmap.
The following parameters are new in this release: mbstart,
mblowat, mbincr, ktextlocal, lotsfree, desfree, minfree,
fsflushr, noautoup, minpagefree
The maxpmem parameter was changed to work on a per-pool
basis and the reserve statement was changed to include cache
mode information.
For more information see the CX/UX System Administration
Manual.
7.10 Device Driver Interfaces
Several routines used by device drivers were changed for
CX/UX Release 7.1. The changes were either needed by the new
memory manager, or needed to improve system performance.
Although device drivers written for previous releases may
need some modification in order to run in this release, the
task of conversion should be straightforward. The sections
that follow describe these changes.
- 37 -
CX/UX 7.1 Release Notes
7.10.1 Memory-Mapped_Devices
Character drivers for memory-mappable devices can now supply
an mmap() or segmap() entry point.
7.10.2 Synchronization_Primitives
The second argument to initlock() must be NULL. Spin locks
are always initialized to the unlocked state.
#include
/* Initialize the spin lock at lockp to the unlocked state. The
* second argument must be NULL.
*/
void
initlock(lock_t *lockp, lockinfo_t *infop)
The second argument to initsema() must be NULL. The
functionality of the old fifo flag can be obtained by
asserting SEMA_FIFO in the third argument. Also, a mutual
exclusion semaphore initialized with the SEMA_NEST flag
allows nested locking; that is, the owner of a mutex is
allowed to re-lock the mutex several times.
#include
/* Initialize the semaphore at semp. The second argument must be
* NULL. Flags include
*
* MUTEX_SEMA initialize a mutual exclusion semaphore
* SEMA_NEST allow nested locking
*
* COND_SEMA initialize an eventcount semaphore
* SEMA_FIFO use FIFO queueing
*/
void
initsema(sema_t *semp, lockinfo_t *infop, int flags)
Mutual exclusion semaphores now allow reader/writer locking.
Write locks are applied by the old pmutex() routine; read
locks are applied by the new rmutex() routine (same calling
sequence as pmutex()). In some cases, the use of read locks
can increase the flow through heavily-traveled critical
sections. Both read and write locks are released by the old
vmutex() routine.
- 38 -
Release Notes 7.1 CX/UX
7.10.3 Virtual_Memory_Primitives
There is a typedef for physical addresses in :
paddr_t.
The old vtop_sys() and vtop_user() routines have been
replaced by the DDI-compliant vtop() routine.
/* Translate virtual address addr in the address space belonging to
* process proc into a physical address. If proc is NULL the
* kernel's address space is used. Returns the physical address if
* successful, 0 otherwise.
*/
paddr_t
vtop(caddr_t addr, struct proc *proc)
The old sptalloc() and sptfree() routines have been replaced
by iomem_alloc() and iomem_free().
#include
/* Allocate len bytes of memory suitable for use as a communication
* area between a device driver and its device. Flags include
*
* IOM_NOSLEEP do not wait for resources to become available
* IOM_CONTIG memory should be physically contiguous
* IOM_DCWRC data cache should be coherent with DMA writes
* IOM_DCRDC data cache should be coherent with DMA reads
*
* The newly allocated memory will always be page-aligned and its
* size will always be rounded up to a multiple of the page size.
* Returns the location of the new storage if successful, NULL
* otherwise.
*/
caddr_t
iomem_alloc(u_int len, u_int iomflags)
/* Free memory previously allocated with iomem_alloc().
*
void
iomem_free (caddr_t addr, u_int len)
The old set_up_pte() and remove_pte() routines have been
replaced by physmap_alloc() and physmap_free().
#include
- 39 -
CX/UX 7.1 Release Notes
/* Allocate virtual address space that is mapped to physical address
* pa for len bytes. Returns the location of the virtual mapping if
* successful, NULL otherwise. Flags include
*
* IOM_NOSLEEP do not wait for resources to become available
*/
caddr_t
physmap_alloc (paddr_t pa, u_int len, u_int iomflags)
/* Free virtual address space previously allocated with
* physmap_alloc().
*/
void
physmap_free (caddr_t addr, u_int len)
7.10.4 Cache-Handling_Primitives
Previous releases used writethrough cache mode for all
kernel data. This release attempts to use copyback cache
mode as much as possible for performance reasons. In
particular, uninitialized, statically-allocated data (the
.bss section) are in copyback mode. To make it easy for
device drivers to statically allocate writethrough storage,
initialized, statically-allocated data (the .data section)
are still in writethrough mode.
In previous releases, device drivers for Series 4000
machines could assume that all memory is DMA write coherent;
in other words, no cache flush is needed prior to a DMA
write. This is no longer the case for Release 7.1. In
general, device drivers must assume that a cache flush is
needed prior to a DMA write unless the memory is known to be
DMA write coherent. DMA write coherent memory can be
allocated with iomem_alloc(). Reserved memory can be made
DMA write coherent in the kernel's configuration file. The
kernel's .data section is DMA write coherent and mbufs are
DMA write coherent. All other memory must be assumed to be
DMA write incoherent.
Although the old P1DC() and uncache() primitives are still
supported, new and greatly improved data cache primitives
are available.
#include
/* Prepare the data cache for DMA in the virtual address range [addr,
* addr+len) in process proc. If proc is NULL the kernel's address
* space is used. Flags include
- 40 -
Release Notes 7.1 CX/UX
*
* DC_ISE DMA is to/from an ISE device (else a VME device)
* DC_READ DMA is read from device (write to primary memory)
* DC_WRITE DMA is write to device (read from primary memory)
* DC_MYCPU my CPU only, ignore other CPUs in the system
*/
void
dcache_previrtdma (caddr_t addr, u_int len, struct proc *proc,
u_int dcflags)
/* Fix the data cache after DMA has occurred in the virtual address
* range [addr, addr+len) in process proc. If proc is NULL the
* kernel's address space is used. Flags are the same as above.
*/
void
dcache_postvirtdma (caddr_t addr, u_int len, struct proc *proc,
u_int dcflags)
/* Prepare the data cache for DMA in the physical address range
* [paddr, paddr+plen). The physical address range must not cross a
* page boundary. Flags are the same as above.
*/
void
dcache_prephysdma (paddr_t paddr, u_int plen, u_int dcflags)
/* Fix the data cache after DMA has occurred in the physical address
* range [paddr, paddr+plen). The physical address range must not
* cross a page boundary. Flags are the same as above.
*/
void
dcache_postphysdma (paddr_t paddr, u_int plen, u_int dcflags)
/* Prepare the data cache for DMA in the range [poff, poff+plen) in
* page frame pp. For convenience, returns the physical address of
* location poff in page frame pp. Flags are the same as above.
*/
paddr_t
dcache_prepagedma (page_t *pp, u_int poff, u_int plen, u_int dcflags)
- 41 -
CX/UX 7.1 Release Notes
8. Direct Software Support
Software support is available from a central source. When
you need assistance or information about your system, please
contact the Harris Software Support Center at our toll free
number (800-245-6453). Our customers outside the
continental United States can contact us directly at 305-
971-6248. The Software Support Center operates Monday
through Friday from 8 a.m. to 7 p.m., Eastern Standard time.
Calling the Software Support Center gives you immediate
access to a broad range of skilled personnel and guarantees
you a prompt response from the person most qualified to
assist you. If you have a question requiring on-site
assistance or consultation, the Software Support Center
staff will arrange for a field analyst to return your call
and schedule a visit.
Harris provides a Software Action Request (SAR) form which
our customers can fill out and submit to their local field
analyst or the Software Support Center. This procedure
ensures that your request is entered into our SAR database
for follow-up and action.
To obtain copies of SAR forms, call the Software Support
Center and request form number CSD1833B.
- 42 -
CONTENTS
1. Introduction............................................. 1
1.1 Boot/miniroot tape................................. 1
1.2 Products tape...................................... 2
2. Documentation............................................ 3
3. Prerequisites............................................ 5
3.1 Hardware Prerequisites............................. 5
3.2 Software Prerequisites............................. 5
4. Installation............................................. 5
4.1 Pre-Installation................................... 5
4.2 Installation Procedure............................. 5
4.3 Post-Installation.................................. 6
4.4 Disk Partition Sizes............................... 6
4.5 Installation Cautions.............................. 7
4.5.1 Placement of the /var Directory............ 7
4.5.2 Optional Products in Alternate
Partitions................................. 8
4.5.3 Latest Release of Optional Products........ 8
5. Cautions................................................. 9
5.1 Kernel Builds...................................... 10
5.2 Future Support..................................... 10
6. New Features in this Release............................. 11
6.1 Shared Objects and Dynamic Linking................. 11
6.2 New Shared Objects................................. 12
6.3 ELF and DWARF File Formats......................... 12
6.4 Software Development Environments.................. 13
6.5 SVR4 Memory Management............................. 17
6.6 POSIX.4............................................ 20
6.7 STREAMS Link Level Driver.......................... 21
6.8 New Libraries...................................... 21
7. Changes from Previous Releases........................... 22
7.1 Compilation Systems................................ 22
7.1.1 C Library.................................. 22
7.1.2 Link Editor................................ 23
7.1.3 Analyze88.................................. 23
7.2 System Daemons..................................... 24
7.3 POSIX.4 Interfaces................................. 24
7.3.1 CX/UX Release 6.2 Changes Affecting
Existing Applications...................... 25
7.3.1.1 Binary semaphores................. 25
7.3.1.2 Clocks and Timers................. 25
- i -
7.3.2 CX/UX Release 7.1 Changes Affecting
Existing Applications...................... 25
7.3.2.1 Counting Semaphores............... 25
7.3.2.2 Real-Time Signals................. 26
7.3.2.3 Synchronized I/O.................. 27
7.3.2.4 Asynchronous I/O.................. 27
7.3.2.5 Clocks and Timers................. 27
7.3.2.6 Interprocess Message Passing...... 28
7.3.2.7 Memory Mapped Files and Shared
Memory............................ 28
7.3.2.8 Real-Time Files................... 28
7.3.3 Other Changes.............................. 28
7.3.3.1 Memory Mapped Files and Shared
Memory............................ 29
7.3.3.2 Interprocess Message Passing...... 29
7.3.3.3 Clocks and Timers................. 29
7.3.3.4 Asynchronous I/O.................. 30
7.3.3.5 Counting Semaphores............... 30
7.4 Core Files......................................... 30
7.5 Utilities.......................................... 30
7.5.1 /etc/rc.................................... 30
7.5.2 fdump(1)................................... 30
7.5.3 tar(1)..................................... 30
7.5.4 mkdir(1)................................... 30
7.5.5 man(1)..................................... 31
7.5.6 login(1)................................... 31
7.5.7 vmstat(1).................................. 31
7.5.8 mpstat(1).................................. 31
7.5.9 pstat(1)................................... 31
7.5.10 ps(1)...................................... 31
7.5.11 top(1)..................................... 31
7.5.12 swapon(1m)................................. 32
7.5.13 swap(1m)................................... 32
7.5.14 ipcs(1).................................... 32
7.5.15 Message Catalogs in Utilities.............. 32
7.6 System Services.................................... 32
7.6.1 fork(2).................................... 32
7.6.2 exec(2).................................... 32
7.6.3 badaddr(2)................................. 33
7.6.4 shmget(2).................................. 33
7.6.5 shmbind(2)................................. 33
7.6.6 shmctl(2).................................. 33
7.6.7 shmat(2)................................... 33
7.6.8 userdma(2)................................. 33
7.6.9 usermap(2)................................. 34
7.6.10 memadvise(2)............................... 34
7.6.11 iconnect(2)................................ 35
7.6.12 ienable(2)................................. 35
7.7 curses............................................. 36
- ii -
7.8 Manual Pages....................................... 36
7.9 Kernel Configuration File.......................... 37
7.10 Device Driver Interfaces........................... 37
7.10.1 Memory-Mapped Devices...................... 38
7.10.2 Synchronization Primitives................. 38
7.10.3 Virtual Memory Primitives.................. 39
7.10.4 Cache-Handling Primitives.................. 40
8. Direct Software Support.................................. 42
- iii -
_________________________________________________________________
HARRIS
COMPUTER SYSTEMS
_________________________________________________________________
CX/UX
VERSION 7.1
RELEASE NOTES
0890108-7.1
October 1993
_________________________________________________________________
Trademark Acknowledgments
CX/UXO is a registered trademark of Harris Corp.,
Computer Systems Div.
Night HawkO is a registered trademark of Harris Corp.,
Computer Systems Div.
NightTraceTM is a trademark of Harris Corp., Computer
Systems Div.
NightViewTM is a trademark of Harris Corp., Computer
Systems Div.
88openO is a registered trademark of the 88open
Consortium, Ltd.
gdbTM is a trademark of the Free Software Foundation.
ABITM is a trademark for Application Binary Interface
UNIXO UNIX is a registered trademark of UNIX System
Laboratories, Inc.
EthernetO is a registered trademark of Xerox Corp.
return to index
================================================================================
CX/RT -
VERSION 7.1
RELEASE NOTES
Harris Computer Systems Division
1. Introduction
CX/RT Version 7.1 includes two products, cx_rt and
cx_rt_develop, to be used in conjunction with CX/UX 7.1. The
cx_rt product consists of the CX/RT kernel, which is a low-
overhead real-time kernel compatible with the CX/UX 7.1
kernel. It is a multiprocessing multithreaded, preemptive
kernel.
2. Documentation
The following documentation is included with this release:
_______________________________________________
| Manual Name Pub. Number|
|________________________________|_____________|
| Real-Time Documentation Set | 0890285-070|
| CX/RT Version 7.1 Release Notes| 0890285-7.1|
|________________________________|_____________|
The CX/RT Reference Manual has been converted to a
documentation set composed of three books:
o Book 1 is entitled Guide to Real-Time Features.
This book contains the information that was formerly in
Part I of the CX/RT Reference Manual-that is, the
overview of the CX/RT product, the real-time kernel,
process scheduling and management, response time,
__________
- These release notes cover the following products: cx_rt
and cx_rt_develop
- 1 -
CX/RT 7.1 Release Notes
real-time peripherals, the frequency-based scheduler,
the performance monitor, and data recording.
o Book 2 is entitiled Guide to Real-Time Services
Utilities.
This book contains the information that was formerly in
Part II of the CX/RT Reference Manual-that is, the
procedures for using the real-time services utilities
rtutil and rtcp and the reference information on the
menus and tasks in rtutil and the commands in rtcp.
o Book 3 is entitled Guide to Real-Time Library
Interfaces.
This book contains the information that was formerly in
Part III of the CX/RT Reference Manual-that is, the
reference information for using the Ada, C, and FORTRAN
library interfaces to the frequency-based scheduler,
the performance monitor, and data recording.
Additional copies may be ordered by contacting the Harris
Software Support Center. The toll-free number for calls
within the continental United States is 1-800-245-6453. For
calls outside the continental United States, the number is
1-305-971-6248.
3. Prerequisites
Prerequisites for CX/RT Version 7.1 are as follows:
3.1 Hardware
o Any Series 4000 or 5000 system
3.2 Software
o CX/UX 7.1
4. Installation
Please refer to the CX/UX System Administration Manual,
Chapter 3, for instructions on software installation.
- 2 -
Release Notes 7.1 CX/RT
Refer to the Real-Time Documentation Set for configuration
instructions specific to cx_rt_develop.
5. Cautions
The real-time data recording program, rt_datarec, requires
that the CX/RT kernel be configured with the frequency-based
scheduler facility, the shared memory mechanism, and the
System V semaphore mechanism.
Due to its vendor-specific nature, the real-time library for
FORTRAN, /usr/lib/libF77rt.a, a part of the cx_rt_develop
product, is not OCSTM (Object Compatibility Standard)
compliant.* FORTRAN object modules compiled in OCS-
compliant mode will not be able to link with this library.
6. New Features in the cx_rt Product
6.1 POSIX.4
The IEEE Draft Standard P1003.4/D14 is now an accepted
standard, which is known as IEEE Standard 1003.1-1993. The
POSIX.4 interfaces are organized as an extension to the
original POSIX.1 standard and will be published as one
entity. CX/UX and CX/RT support all functional areas as
specified by this new standard. Note that computer vendors
cannot claim compliance to this standard because currently
there is no test suite to verify compliance.
Refer to the CX/UX Version 7.1 Release Notes for a list of
all of the POSIX.4 functional areas and the name of the
chapter and manual in which the corresponding interfaces are
documented.
Applications that were written for previous CX/UX and CX/RT
releases, which supported other drafts of the POSIX.4
interfaces, might need modification to operate under this
release. Please see the section entitled "Changes from
Previous Releases" for additional information.
__________
* OCS is a trademark of the 88open Consortium Ltd.
- 3 -
CX/RT 7.1 Release Notes
7. Changes from Previous Releases
7.1 Changes to POSIX.4 Interfaces
POSIX.4 interfaces that were released in previous CX/UX and
CX/RT releases have been based on various IEEE Draft
Standards. CX/UX and CX/RT support POSIX.4 interfaces that
are specified in the final version of this standard, IEEE
Standard 1003.1-1993. Some of the changes that have been
made to update the POSIX.4 functional areas to support this
standard will cause source incompatibility for existing
programs that are based on previous releases of the POSIX.4
interfaces. It is recommended that all applications that
utilize any of the POSIX.4 interfaces be recompiled with the
new release. Compilation errors will indicate most areas
where source incompatibility exists. Recompilation will
also update the application so that it is using the most
up-to-date POSIX.4 library routines, some of which contain
performance improvements in this release.
Please see the section entitled "Changes from Previous
Releases" in the CX/UX Version 7.1 Release Notes for
specific details on which POSIX.4 interfaces have changed to
support the final version of this standard. Note the
following in the "POSIX.4 Interfaces" section:
o The sections entitled "CX/UX Version 6.2 Changes
Affecting Existing Applications" and "CX/UX Version 7.1
Changes Affecting Existing Applications" document the
changes that must be made to source code that utilizes
the POSIX.4 interfaces that have been released in
previous CX/UX and CX/RT releases. The changes
required in an application that utilizes POSIX.4
interfaces depends upon the operating system release
for which the application was originally written. The
changes required are documented according to the
release to which the user is upgrading. The changes
required are cumulative; for example, if the source
code was originally developed under release 6.1, then
the changes made in releases 6.2 and 7.1 must all be
applied to the application source code.
Note: You need to concern yourself with these sections
only if you have existing programs that use
POSIX.4 interfaces from previous releases.
o Some of the changes that have been made to update the
POSIX.4 functional areas to support the final version
of the POSIX standard will not cause source
- 4 -
Release Notes 7.1 CX/RT
incompatibility for existing programs that are based on
previous versions of the related interfaces. The
section entitled "Other Changes" describes changes to
the interfaces that will not require source changes in
applications that were built to use previous versions.
7.2 Change Regarding nanosleep Documentation
In previous releases, the POSIX.4 nanosleep(3P4) routine has
been documented in the CX/RT Reference Manual in the chapter
entitled "Improving Response Time." In release 7.1, this
routine is documented with the other POSIX.4 clocks and
timers interfaces in the CX/UX Programmer's Guide in the
chapter entitled "Timing Facilities."
8. Direct Software Support
Software support is available from a central source. When
you need assistance or information about your system, please
contact the Harris Software Support Center at our toll free
number (800-245-6453). Our customers outside the
continental United States can contact us directly at 305-
971-6248. The Software Support Center operates Monday
through Friday from 8 a.m. to 7 p.m., Eastern Standard time.
Calling the Software Support Center gives you immediate
access to a broad range of skilled personnel and guarantees
you a prompt response from the person most qualified to
assist you. If you have a question requiring on-site
assistance or consultation, the Software Support Center
staff will arrange for a field analyst to return your call
and schedule a visit.
Harris provides a Software Action Request (SAR) form which
our customers can fill out and submit to their local field
analyst or the Software Support Center. This procedure
ensures that your request is entered into our SAR database
for follow-up and action.
To obtain copies of SAR forms, call the Software Support
Center and request form number CSD1833B.
- 5 -
CONTENTS
1. Introduction.............................................. 1
2. Documentation............................................. 1
3. Prerequisites............................................. 2
3.1 Hardware............................................. 2
3.2 Software............................................. 2
4. Installation.............................................. 2
5. Cautions.................................................. 3
6. New Features in the cx_rt Product......................... 3
6.1 POSIX.4.............................................. 3
7. Changes from Previous Releases............................ 4
7.1 Changes to POSIX.4 Interfaces........................ 4
7.2 Change Regarding nanosleep Documentation............. 5
8. Direct Software Support................................... 5
- i -
_________________________________________________________________
HARRIS
COMPUTER SYSTEMS
_________________________________________________________________
CX/RT
VERSION 7.1
RELEASE NOTES
0890285-7.1
November 1993
_________________________________________________________________
return to index
================================================================================
DR11W -
VERSION 7.1
RELEASE NOTES
Harris Computer Systems Division
1. Introduction
The DR11W emulator is a high-speed, 16-bit parallel DMA
interface between the CX systems and most DR11W-compatible
devices, including other DR11W emulators. Furthermore, the
DR11W emulator provides several real-time features, such as
I/O directly to/from a process's address space, asynchronous
I/O support, three attention interrupt notification
mechanisms, and a 32 megabyte DMA transfer capability.
A set of library routines can be obtained to access the
DR11W device directly from user space. The source code to
this user level driver is provided so that the driver can be
modified to perfectly fit the needs of a given application.
Performing I/O through the user-level driver can provide a
tremendous improvement in reducing the overhead of issuing
an I/O request.
Refer to the CX/UX Programmer's Guide for complete
information.
2. Documentation
The following documentation is included with this release:
___________________________________
| Manual Name Pub. Number|
|____________________|_____________|
|____________________|_____________|
__________
- These release notes cover the following products: dr11w
- 1 -
DR11W 7.1 Release Notes
| DR11W Release Notes| 0890303-7.1|
|____________________|_____________|
Additional copies may be ordered by contacting the Harris
Software Support Center. The toll-free number for calls
within the continental United States is 1-800-245-6453. For
calls outside the continental United States, the number is
1-305-971-6248.
3. Prerequisites
Prerequisites for DR11W Version 7.1 are as follows:
3.1 Hardware
o Any Series 4000 or 5000 system
o DR11W emulator
3.2 Software
o CX/UX 7.1
4. Installation
Please refer to the CX/UX System Administration Manual,
Chapter 3, for instructions on software installation.
5. Cautions
None.
6. New Features in this Release
None.
- 2 -
Release Notes 7.1 DR11W
7. Changes from Previous Releases
The DR11W_EPOLL ioctl(2) requires that both the current CPU
and the CPU servicing the DR11W interrupt have the same
local/global/remote relationship with the polling address.
If this is not the case, an error is returned; for example,
if the polling address is in a memory pool that is local to
the current CPU but is remote to the CPU that will
eventually service the DR11W interrupt, an error will be
returned.
8. Direct Software Support
Software support is available from a central source. When
you need assistance or information about your system, please
contact the Harris Software Support Center at our toll free
number (800-245-6453). Our customers outside the
continental United States can contact us directly at 305-
971-6248. The Software Support Center operates Monday
through Friday from 8 a.m. to 7 p.m., Eastern Standard time.
Calling the Software Support Center gives you immediate
access to a broad range of skilled personnel and guarantees
you a prompt response from the person most qualified to
assist you. If you have a question requiring on-site
assistance or consultation, the Software Support Center
staff will arrange for a field analyst to return your call
and schedule a visit.
Harris provides a Software Action Request (SAR) form which
our customers can fill out and submit to their local field
analyst or the Software Support Center. This procedure
ensures that your request is entered into our SAR database
for follow-up and action.
To obtain copies of SAR forms, call the Software Support
Center and request form number CSD1833B.
- 3 -
CONTENTS
1. Introduction.............................................. 1
2. Documentation............................................. 1
3. Prerequisites............................................. 2
3.1 Hardware............................................. 2
3.2 Software............................................. 2
4. Installation.............................................. 2
5. Cautions.................................................. 2
6. New Features in this Release.............................. 2
7. Changes from Previous Releases............................ 3
8. Direct Software Support................................... 3
- i -
_________________________________________________________________
HARRIS
COMPUTER SYSTEMS
_________________________________________________________________
DR11W
VERSION 7.1
RELEASE NOTES
0890303-7.1
November 1993
_________________________________________________________________
return to index
================================================================================
OSI FTAM -
VERSION 7.1
RELEASE NOTES
Harris Computer Systems Division
1. Introduction
The OSI (Open Systems Interconnection) FTAM (File Transfer,
Access, and Management) software package allows the transfer
and remote access of files between Harris hosts (computers),
and between Harris hosts and hosts from other vendors who
run the OSI FTAM protocol as specified by the ISO
(International Standards Organization) 8571 standard.
OSI FTAM is based upon the FTAM software package developed
by Retix and operates in a STREAMS-based environment. OSI
FTAM requires the usage of the OSI LAN Transport software
package to provide the lower protocol layers (Transport and
Networking Layers) needed for communication in an OSI
environment.
OSI FTAM supports the FTAM-1 Unstructured Text, FTAM-2
Sequential Text, FTAM-3 Unstructured Binary, NBS-9 Directory
Filenames, and NBS-10 Random Binary Access document file
types.
The OSI FTAM product also supports an application program
interface (API) library based on the Manufacturing
Automation Protocol (MAP)/Technical and Office Protocol
(TOP) Version 3.0 standard.
__________
- These release notes cover the following products: ftam
- 1 -
OSI FTAM 7.1 Release Notes
2. Documentation
The following documentation is included with this release:
_________________________________________________________
| Manual Name Pub. Number|
|__________________________________________|_____________|
| OSI FTAM Administration Guide | 0890411-000|
| OSI FTAM Programmer Guide | 0890443-000|
| OSI FTAM User Guide | 0890445-000|
| OSI Upper Layers Common Facilities Manual| 0890447-000|
| OSI FTAM Version 7.1 Release Notes | 0890411-7.1|
|__________________________________________|_____________|
Additional copies may be ordered by contacting the Harris
Software Support Center. The toll-free number for calls
within the continental United States is 1-800-245-6453. For
calls outside the continental United States, the number is
1-305-971-6248.
- 2 -
Release Notes 7.1 OSI FTAM
3. Prerequisites
Prerequisites for OSI FTAM version 7.1 are as follows:
3.1 Hardware
o Any Harris Series 4000 or 5000 system.
o Special hardware is needed and is dependent upon the
type of network on which OSI FTAM is run. One or more
of the following is needed: an Ethernet controller
and/or an FDDI controller.
3.2 Software
o CX/UX 7.1
o STREAMS 7.1
o OSI LAN Transport 7.1
o Ethernet 7.1
4. Installation
Refer to the CX/UX System Administration Manual, Chapter 3,
for instructions on software installation.
4.1 Product Installation
The OSI FTAM product is installed in the following fashion:
/etc - Contains OSI FTAM configuration files.
/usr/bin/osi - Contains OSI FTAM commands.
/usr/catman - Contains on-line versions of all OSI FTAM
man pages.
/usr/etc/ftam - Contains OSI FTAM filestore daemons,
databases, and auditing. NOTE: Administrators should
ensure that this directory has full read, write, and
execute access for all groups. This will permit access to
the filestore databases by all FTAM utilities/application
- 3 -
OSI FTAM 7.1 Release Notes
programs.
/usr/etc/ftam/demo - Contains FTAM MAP/TOP 3.0 Application
Program Interface (API) demo program source code.
/usr/include/ftam - Contains various header files used by
the FTAM MAP/TOP 3.0 Application Program Interface (API)
library.
/usr/include/ulcommon - Contains API OSI upper layers
header files.
/usr/lib/ftam - Contains various libraries used by the
FTAM MAP/TOP 3.0 Application Program Interface (API)
library.
/usr/lib/ulcommon - Contains API OSI upper layers
libraries.
/usr/man - Contains formatted source code versions of all
OSI FTAM man pages.
/var/spool/ftam - Initially empty directory which will
contain keys to message queues utilized by the OSI FTAM
virtual filestore. NOTE: Administrators should ensure
that this directory has full read, write, and execute
access so that the filestore and lockmgr daemons can
function properly.
4.2 Kernel Configuration
Once the OSI FTAM software has been installed, the kernel
must be configured and rebuilt to support the OSI LAN
Transport stack over which the OSI FTAM product must run.
To do this, verify that the OSI LAN Transport stack product
has been installed and then uncomment the following options
in the kernel configuration file prior to kernel
recompilation:
mbufs #See OSI LAN Transport, Ethernet Release Notes
(0890419)
options STREAMS #STREAMS support
options "NSTRPUSH" #No. of pushes per stream
options "STRCTLSZ" #Max size of control portion of any
message
- 4 -
Release Notes 7.1 OSI FTAM
options NCLONE #Clone driver minor devices
options NLOG #Optional: Log driver minor devices
options NTIRDWR #TLI read/write module minor devices
options NTIMOD #TLI cooperating module minor devices
options OSILAN #OSI LAN Transport stack support
Depending on the system's hardware configuration, uncomment
one or more of the following kernel configuration file
options to configure LAN controllers prior to kernel
recompilation:
device pg[0-2] #Interphase 4211 Peregrine FDDI
controller
device ie[0-3] #Integral Ethernet controller
device eg[0-3] #Interphase 4207 Eagle Ethernet
controller
Refer to the CX/UX System Administration Manual, Chapter 4,
for instructions on configuring and building a kernel.
Also refer to the OSI LAN Transport, Ethernet Release Notes
(Publication #0890419) for further information on OSI LAN
Transport stack building and configuration on your system.
4.3 /etc/rc Script Modifications
Examine the /etc/rc and the /etc/shutdownrc scripts for OSI
LAN Transport and OSI FTAM-specific options which must be
uncommented prior to rebooting the OSI-configured kernel.
4.4 Application Entity Table
The OSI hosts address file __AETABLE__ is installed under
the directory /usr/etc/ftam. This file is accessed by all
OSI application software packages to determine the OSI
addresses of host systems (also known as application
entities or AEs in OSI terms). All of the OSI applications
expect the __AETABLE__ file to reside under the /etc
directory. Therefore, this file must be eventually moved to
the /etc directory prior to activating or using any of the
OSI applications. Since this file is released with every
- 5 -
OSI FTAM 7.1 Release Notes
OSI application, it is placed under the /usr/etc/XXX
directory (where XXX refers to the particular OSI
application) to prevent accidental overwrite of an existing
__AETABLE__ file in the /etc directory. OSI administrators
do not need to access each __AETABLE__ file in each OSI
application's /usr/etc directory, but either make only one
copy of the file for global use in the /etc direc