.if n .pH rn4.chap2 @(#)chap2	40.37
.\" Copyright 1989 AT&T
.BK "Software Notes"
.CH "Operating System" "2"
.H 1 "Operating System Notes"
.IX istart UNIX System V Release 4, operating system notes
.H 2 "Security"
.IX security, per process resource limits
The kernel has been changed to re-initialize all per-process 
resource limits to the system defaults provided in the 
kernel's \f4master\fP file whenever a set-user-ID or set-group-ID file is \f4exec\f1'd.
.IX \f4exec\fP(2)
These limits include both the new BSD-style resource limits 
[see \f4getrlimit\f1(2)] and pre-SVR4.0 resource limits 
[see \f4ulimit\f1(2)].
In all other cases, 
per-process resource limits are inherited across \f4exec\f1 as they 
have been in the past.  This change prevents unprivileged 
processes from causing privileged processes to fail by 
depriving them of necessary resources.
.H 2 "Service Access Facility"
.IX \f4/etc\fP, \f4ttydefs\fP
.IX \f4/etc\fP, \f4gettydefs\fP
.IX \f4/etc\fP, \f4inittab\fP
.IX \f4ttymon\fP(1M)
.IX \f4ttydefs\fP
.IX \f4getty\fP(1M)
.P
Under the new Service Access Facility,
tty ports are now monitored by \f4ttymon\f1, a STREAMS-based
tty port monitor that can monitor one or more ports.
All the \f4getty\f1 and \f4uugetty\f1 entries in \f4/etc/inittab\f1 
are converted to equivalent entries under
\f4ttymon\f1.
\f4/etc/gettydefs\f1 is replaced by a new formatted file, 
\f4/etc/ttydefs\f1.
For compatibility, \f4getty\f1 is currently a symbolic link to
\f4ttymon\f1. 
The \f4/etc/getty\f1 link may be discontinued in future releases.
.P
If the \f4getty/uugetty\f1 configurations in the old 
\f4/etc/inittab\f1 are desired, a command, \f4ttyconv\f1 
will convert all \f4getty/uugetty\f1
entries in \f4/etc/inittab\f1 to equivalent setups under \f4ttymon\f1.
The \f4ttyconv\f1 command also converts \f4/etc/gettydefs\f1 
to \f4/etc/ttydefs\f1, if the \f4/etc/gettydefs\f1 file 
exists on the system.  The conversion should be done in 
single user or administration mode.
There are many changes to \f4/etc/inittab\f1 entries.
Direct copying of the old \f4/etc/inittab\f1 file over the new one
is not recommended.
.H 2 "Source Compatibility Problems"
.H 3 "Header Files"
.IX header files, pre-Release 4 source compatibility
Header file enhancements in SVR4.0 may cause compilation
errors in pre-SVR4.0 applications.  In a small number of
cases, header file names may need to be changed, or new
header files added to pre-SVR4.0 program source code.
.P
For example, the header file
\f4sys/param.h\f1 no longer 
includes \f4sys/fs/s5param.h\f1 and 
an error may occur during compilation if a customer
compiles a pre-SVR4.0 program which requires s5 filesystem 
specific parameters.  If an error for an undefined reference occurs
check to see which header file contains the
undefined symbol.  Include the \f4sys/fs/s5param.h\f1 
file in the program code.
.H 4 "Header Files and POSIX Type Definitions"
.IX POSIX conformance, header files
The convergence of standards in SVR4.0 has introduced a number
of new names into header files.  It is inevitable that these
new names may cause compilation errors.  The simplest solution to 
these errors is to rename conflicting identifiers.
.P
The following list includes some of the new POSIX
type definitions which have been introduced into SVR4.0.
.TS
center box;
l	l
lf4	l.
Defined Types	Description
_
\f4dev_t\f1	Used for device numbers.
\f4gid_t\f1	Used for group IDs
\f4ino_t\f1	Used for file serial numbers.
\f4mode_t\f1	Used for some file attributes
\f4nlink_t\f1	Used for link counts.
\f4off_t\f1	Used for file sizes.
\f4pid_t\f1	Used for process IDs and process group IDs.
\f4uid_t\f1	Used for user IDs.
.TE
.H 2 "Expanded Fundamental Types"
.IX istart EFT (Expanded Fundamental Types)
.IX istart Expanded Fundamental Types (EFT)
This section presents a brief discussion of the     
expanded size of the fundamental operating 
system types (EFT) in SVR4.0 and their possible 
impact on future application code development.  
SVR4.0 provides for the expansion of certain 
defined kernel data types which were formerly 
defined as 2-byte types.  Included in table 2-1 
is the list of expanded fundamental data types in SVR4.0.
.P
The resource demands placed on the UNIX operating 
system by implementation on larger machines, 
together with the advent of distributed networks 
and the evolution of the operating system, has 
contributed to defined data types exceeding their 
original design capacities of two bytes.  For example, 
some UNIX implementations have worked around the 
shortage of minor device numbers by assigning 
multiple major numbers to a single driver.  
This has generated a need to expand the limits 
on these data types.  The EFT feature in SVR4.0 
will answer this need.
.H 3 "The EFT Feature"
In the kernel and in ``new''
drivers, the definition for certain UNIX System fundamental data
types will be four bytes instead of the two or one as 
in pre-SVR4.0 systems.
We call these defined data types ``fundamental'' because 
their use pervades most of the UNIX System. 
.P
The expansion allows for a period of transition to 
ensure compatibility for the installed base of 
UNIX Systems.  Therefore, in SVR4.0 the expansion 
has been designed to offer coexistence between 
the existing base of software and the present and 
future need to provide for the support of larger 
configurations.  In SVR4.0, the type expansion provides, 
in most cases, forward application source and binary 
compatibility for pre-SVR4.0 systems.
Source and object compatibility will be supported 
in SVR4.0 for those drivers written to the AT&T 
Device Driver Interface (DDI) specification. 
STREAMS-based drivers, however, will have to 
be recompiled.  It must be understood, however, 
that software affected by EFT will have to be 
modified to include the POSIX and System V 
defined \f4typedefs\f1 in table 1 before 
values for the EFT data types grow beyond the 
2-byte boundary. 
See the section
.ST "Some General Pointers for Applications Development"
for exceptions.
.P
Table 2-1 lists the fundamental data types affected by the 
EFT expansion along with their underlying type.  The ``New Name''
column indicates whether the symbolic type name 
(e.g. \f4uid_t\f1) is new in SVR4.0.
.TB "Basic EFT Data Types"        
.TS
center, box;
c| c| c| c
cf2 | lfCW| afCW| c.
Type	Name	Underlying Type	New Name 
=
uid	uid_t	long	yes
_
gid	gid_t	long	yes
_
pid	pid_t	long	yes
_
ino	ino_t	ulong	no
_
dev	dev_t	ulong	no
_
mode	mode_t	ulong	yes
_
nlink	nlink_t	ulong	yes
_
major	major_t	ulong	yes
_
minor	minor_t	ulong	yes
_
.TE
.P
These types will, by default, be four bytes in 
any application that uses them.
.P
As mentioned earlier, however, this does not mean that 
applications will fail in SVR4.0.
For example, if an application were to pass the 
\f4chown\f1 system call
a \f2uid\f1 and \f2gid\f1 of type \f4int\f1 
(or even \f4short\f1),
everything will still work because the arguments are 
automatically promoted.
Also, \f4stat\f1 will continue to work even if you copy 
a \f2value\f1 from the \f4stat\f1 structure 
into a \f4short\f1 or an \f4int\f1 because of 
automatic demotion.
The reason this works is that, even though the \f2sizes\f1
of the fields are larger in SVR4.0, the 
\f2values\f1 are being kept within    
their pre-SVR4.0 limits.  For example, the \f4stat\f1 
structure can now hold a \f2uid\f1 of over 2 
billion, but to maintain compatibility with 
existing binary applications, the maximum value for 
a \f2uid\f1 will fit in 2-bytes for SVR4.0.
See the section
.ST "Some General Pointers for Applications Development"
for exceptions to this rule.
.P
These restrictions on values will be maintained for at 
least SVR4.0, but will be relaxed beyond SVR4.0 
(and may be relaxed in certain binary releases, 
as decided by the source licensee building the binary). 
Applications are thus strongly urged to start 
using the new symbolic types.  For example, every 
declaration of a \f2uid\f1 should be changed 
from \f4int\f1 or \f4short\f1 to \f4uid_t\f1. 
This will ensure that when these limits are 
relaxed in the future, application compatibility
will not be affected.   
.IX iend EFT (Expanded Fundamental Types)
.IX iend Expanded Fundamental Types (EFT)
.H 2 "Some General Pointers for Applications Development"
In SVR4.0, although forward \f4a.out\f1 compatibility 
is supported, there are certain conditions 
where ``\f4.o\f1'' and source compatibility problems may arise. 
The following conditions should serve as general
caveats for applications as well as for kernel functions:
.BL
.LI
The linking of EFT and non-EFT object (\f4.o\f1) 
files that pass EFT structures, or
reference EFT structures by address may
result in a corrupted \f4a.out\f1 file.  This 
incompatibility is assumed to be small
as it deviates from portable coding standards.  Since 
the values for EFT data types
will remain small in SVR4.0, parameter passing 
by value will be unaffected with the
exception of \f4dev_t\f1 (see below).   
.LI
An incompatibility will arise in source code that 
references EFT data types by
address (pointers) when their underlying  
C type has a different size than the object it references.
For example, the \f4st_uid\f1 field in \f4stat\f1(2) is 
a 2-byte integral type in pre-SVR4.0 systems.
For EFT, this field is a 4-byte integral
type.  Applications that previously used a 
short-pointer to reference \f4st_uid\f1
will break when compiled in a SVR4.0 environment. 
Although the above coding example
is not considered portable, to work in SVR4 
the pointer declaration for a \f4uid\f1
object must be to type \f4uid_t\f1.
.P
User level source code affected by EFT can defer 
source migration in SVR4.0 
by defining the feature test macro \f4_STYPES\f1 
to obtain the pre-SVR4.0 system definitions 
(where fundamental data types
will be small and pre-SVR4.0 interfaces used). 
Affected kernel source will have to
be changed to work in SVR4.
.LI
Although automatic promotion and demotion of arguments is 
available in SVR4.0 (for maximum portability 
during the transition period), formatted data types 
are not subject to this process.  For example, 
the \f4st_dev\f1 data type includes two 
components, a major and minor device number. 
In SVR4, the major device number occupies the upper 
14 bits and minor number lower 18 bits of 
\f4dev_t\f1.  If the device number is assigned 
to a variable two bytes wide, then the device 
number will be truncated.  This is the only case 
in EFT where pass-by-value will be affected when
the receiving variable is two bytes wide. 
This incompatibility is assumed to be small
since pre-SVR4.0 source code should already 
include \f4dev_t\f1 declarations.
.LI
The accounting data file has been expanded in SVR4.0 
to support EFT data types.  The accounting flag \f4ac_flag\f1 
has been set to \f4AEXPND\f1 to indicate an 
SVR4.0 account file.  This may cause 
potential incompatibility since some software 
has dependencies on this file.  This incompatibility 
is small and affects mostly administrative programs.
.LI
The archive format for \f4cpio\f1 changed in SVR4.0 to 
support EFT.  In SVR4, the \f4cpio\f1
header will default to EFT.  Consequently,
\f4cpio\fP archives that will be restored on
pre-SVR4.0 systems should be created with the 
\f4-H odc\f1 option [see \f4cpio\fP(1) and \f4cpio\fP(4)].
.IX \f4cpio\fP(1)
.LE
.H 2 "STREAMS"
.IX STREAMS, \f4st_size\fP return
.P
Since a pipe in System V Release 4.0 is bi-directional,
there are two separate data flows.  Therefore, the size
\f4st_size\f1 returned by a call to \f4fstat\f1(2), where the
argument is the file descriptor of either end of the pipe,
is the number of bytes available for reading from that file
descriptor.  Previously, the size \f4st_size\f1 returned by
a call to \f4fstat\f1(2), where the argument was the write-end
of a pipe, was the number of bytes available from the
read end.
.H 4 STRMSGSZ
.IX \f4STRMSGSZ\fP parameter
.P
Any code written for STREAMS drivers that expected
\f4STRMSGSZ\f1 to be greater than \f40\f1 should 
note that \f40\f1 is now a legal value for 
\f4STRMSGSZ\f1.
.H 4 "Flush Handling"
.IX flush handling, pre-Release 4 modules
Flush handling has been expanded in STREAMS to include
flushing up to 256 individual bands of data flow.  Users
of pre-System V Release 4.0 modules should be aware that
a flush message to these modules will flush all of the 
queues of data. 
.H 4 "Multiple Bands of Data Flow"
A \f4poll\f1 with event type \f4POLLWRBAND\f1 indicates whether there exists
a priority band greater than \f40\f1 of a queue downstream that is
writable.  The only bands that are checked are those that are
less than or equal to the highest band that has been written to
so far.
.H 4 RFS
.IX RFS, STREAMS \f4ioctl\fP system call
.IX \f4ioctl\fP(2), named streams over RFS
The semantics of the STREAMS \f4ioctl\f1 system calls on 
named streams over RFS are not supported entirely.
Also note that modules pushed on a named stream over RFS from
a remote machine may not give the expected results.
.H 4 TTY
.IX STREAMS, terminal subsystem
.IX terminal line discipline
The terminal subsystem in SVR4.0 has been converted 
to utilize the STREAMS-based character I/O mechanism. 
All the drivers including console, ports, XT and SXT 
have been converted to STREAMS.  The \f4clist\f1 character 
I/O mechanism has been removed from the system.
Although \f4clists\f1 can be reinstated easily, it is 
strongly recommended that all the drivers be 
converted to STREAMS.
Many commands (such as \f4strconf\f1, \f4strchg\f1, 
\f4ttymon\f1, \f4layers\f1, and \f4shl\f1) assume a 
STREAMS driver.
.P
The SVR4.0 terminal subsystem provides SVR3.x, POSIX, 
BSD and XENIX compatibility.  SVR3.x and 
POSIX functionality has been included in 
the standard terminal line discipline 
(\f4ldterm\f1) and the drivers.  There is some BSD 
functionality such as in \f4word\f1 \f4erase\f1, \f4reprint\f1, \f4echo\f1 
\f4control\f1 that is part of the standard 
line discipline.  These BSD enhancements are 
all controlled using the flag \f4IEXTEN\fP (which 
is turned off by default).  The BSD and XENIX 
terminal \f4ioctl\f1 compatibility is provided by 
pushing a specialized line discipline (\f4ttcompat\f1) 
on the top of the standard line discipline.  While 
\f4ttcompat\f1 allows most BSD and XENIX terminal 
applications to be run on SVR4.0, it is 
recommended that the applications be converted 
to POSIX \f4termios\f1 or \f4termio\f1(7) interface to follow 
the future direction.  BSD applications should 
use \f4/usr/ucbinclude/sys/ioctl.h\f1 instead of 
\f4/usr/include/sys/ioctl.h\f1.  All other 
BSD terminal related files are in 
\f4/usr/include/sys\f1.
.H 4 ptys
.IX pseudo-tty subsystem
Along with hardware STREAMS drivers, 
SVR4.0 provides a STREAMS-based
pseudo-terminal subsystem (ptys). 
ptys are useful for remote login
and windowing types of applications.
.H 3 "Source Compatibility"
.IX STREAMS, public and private pieces
Source compatibility has been maintained 
for STREAMS code.  Note, however, that with 
the enabling of EFT, much information has 
been moved and has changed size.  The STREAMS 
source code has also been reorganized into 
``public'' and ``private'' pieces.  The header 
file \f4sys/stream.h\f1 contains the public 
data structures that modules or drivers 
may need to reference.
The header file \f4sys/strsubr.h\f1 contains 
data structures private to the STREAMS 
subsystem, which should \f2not\f1 be 
referenced by drivers or modules.
Likewise, \f4io/stream.c\f1 contains utility 
routines that a driver or module may call, 
and \f4os/strsubr.c\f1 contains routines 
that are private to the STREAMS subsystem, 
which should \f4not\f1 be called by any driver
or module.
.H 2 "Virtual Memory"
.H 3 "Swap Space Configuration"
.IX swap space, requirements increased
.IX memory management, swap space requirements
An SVR4.0 system may need more swap space 
(an increase bounded by the size of real memory) 
to run a load that ran under SVR3.
SVR3 attempted to use the sum of real memory and swap space
for what SVR4.0 calls anonymous memory (memory without real file backup).
The SVR3 method had some design holes that could cause a deadlock,
but it did allow configurations with large amounts of real memory
and small amounts of swap space to run loads whose use of anonymous
memory exceeded the available swap space.
Under SVR4.0, swap space is required for all anonymous memory
(which avoids the deadlock issues of SVR3).
The SVR3 deadlock problems come from pages having both a swap
and a real memory association after swap in while being counted only once.
The SVR4 approach avoids this by needing swap space for 
all anonymous memory. 
.H 2 "File-System-Independent Booting"
.P
.IX boot, file system
.IX \f4bfs\fP (boot file system), unsupported features
The BFS file system type does not support
the following features:
.DL
.LI
\f4mmap\fP(2)
.LI
truncate up
.LI
symbolic links
.LI
\f4volcopy\fP(1M)
.LI
\f4labelit\fP(1M)
.LI
\f4mkdir\fP(1)
.LE
.H 2 "Autoconfiguration"
.IX autoconfiguration
.P
There are a few items to take note of when 
re-configuring and booting.
.AL
.LI
.IX boot, need for bootable UNIX
The bootstrap program presumes a bootable \f4unix\f1 (at least \f4mUNIX\fP), 
exists on the hard disk, in \f4/stand\f1.
It is no longer possible to boot and configure the system without 
a bootable \f4unix\f1.
(For example, you can not boot \f4/etc/system\f1
without an existing bootable \f4unix\f1).
.LI
.IX \f4/boot\fP, and ELF%boota, and ELF
If any of the boot modules in \f4/boot\f1 are built with the 
ELF Compilation System they are ELF binaries.
If \f4cunix\f1 encounters an ELF binary, it will presume an ELF CCS, and execute
an ELF link-editor to build a resulting ELF \f4/unix\fP.
If all boot modules are COFF, \f4cunix\fP will presume a COFF system and
execute a COFF link-editor, producing a COFF \f4/unix\fP.
.LI
The file \f4/sbin/buildsys\f1 contains information for 
\f4cunix\f1 to use for an autoconfiguration scenario.
.LE
.H 2 "Signals"
.IX signals, source compatibility
.IX signals, future directions
.H 3 "Source Compatibility"
Two new signals, \f4SIGXCPU\f1 and \f4SIGXFSZ\f1 have been added.
To prevent these signals from being sent to processes unprepared
to accept them, processes by default inherit a 
\f4SIG_IGN\f1 disposition for them from \f4init\f1.  
Processes must explicitly change that disposition 
in order to receive them.
.H 3 "Future Directions"
In the future, \f4init\f1 will no longer cause its 
children to inherit a \f4SIG_IGN\fP disposition for 
\f4SIGXCPU\f1 and \f4SIGXFSZ\f1.
.IX iend UNIX System V Release 4, operating system notes
