svr4(4)

NAME

svr4 - System V Release 4 ABI support

SYNOPSIS

To link System V Release 4 (SVR4) ABI support into the  kernel:
options COMPAT_SVR4
To load the SVR4 ABI support kernel module:
      kldload svr4

DESCRIPTION

The svr4 module provides limited System V Release 4 ABI (ap

plication
binary interface) compatibility for userland applications.

The module
provides the following significant facilities:

+o An image activator for correctly branded elf(5) exe

cutable images

+o Special signal handling for activated images

+o SVR4 to native system call translation

+o STREAMS network API emulation (via the streams(4) load

able module, or

by means of

device streams

in a kernel configuration file)

+o Mappings between FreeBSD and SVR4 ioctl(2) calls, or,

where no such

mappings exist, reverse-engineered implementations of

the SVR4 calls.

It is important to note that the SVR4 ABI support it not

provided through
an emulator. Rather, a true (albeit limited) "clean room"

reverse-engineered ABI implementation is provided.

LIMITATIONS

Because the provided ABI has been developed in ignorance of

actual SVR4
source code, there are bound to be unforeseen interactions

between SVR4
client applications and the emulated ABI which cause appli

cations to malfunction.

Additionally, some SVR4 operating systems do not adhere to

the SVR4 ELF
standard. In particular, Solaris does not set the ELF in

terpreter field
in the ELF header to a value which would allow the kernel to

correctly
identify a client executable as an SVR4 application. Thus,

in certain
instances it is necessary to use the brandelf(1) utility to

explicitly
brand the executable, or to set the kern.fallback_elf_brand

sysctl(8)
variable to define a "default" ABI for unbranded executa

bles. Value
ELFOSABI_SOLARIS represents Solaris; ELFOSABI_SYSV repre

sents other
SysVR4 operating systems. See #include <sys/elf_common.h> for ELFOSABI branding definitions, and brandelf(1) for in

formation on
branding executables.

The svr4 module can be linked into the kernel statically

with the
COMPAT_SVR4 kernel configuration option or loaded as re

quired. The following command will load the module if it is neither linked

into the kernel nor already loaded as a module:

if ! kldstat -v | grep -E 'svr4elf' > /dev/null; then

kldload svr4 > /dev/null 2>&1

fi

The kernel will check for the presence of the streams(4)

module, and load
it if necessary.

Note that dynamically linked SVR4 executables will require a

suitable
environment in /compat/svr4.

For information on loading the svr4 kernel loadable module

automatically
on system startup, see rc.conf(5). This information applies

regardless
of whether the svr4 module is statically linked into the

kernel or loaded
as a module.

STREAMS emulation is limited but (largely) functional. As

suming the
streams(4) module is loaded, a STREAMS handle can be ob

tained by opening
one of the relevant files in /dev or /compat/svr4/dev. In

ternally, the
streams(4) driver produces a socket descriptor and ``tags''

it with additional STREAMS state information before returning it to the

client application. The svr4 environment uses the additional state in

formation to
recognize and manipulate emulated STREAMS handles when

STREAMS-specific
ioctl(2) calls are executed.

The subset of STREAMS functionality which is provided is

small, probably
little more than what is required to enable programs on the

Solaris CD
sets to run.

FILES

/compat/svr4 minimal SVR4 run-time en

vironment
/sys/compat/svr4/syscalls.master mappings between SVR4

syscalls and svr4

module entrypoints.

SEE ALSO

brandelf(1), streams(4), elf(5)

HISTORY

System V Release 4 ABI support first appeared in FreeBSD

4.0. The ABI
was ported from an equivalent facility present in NetBSD 1.3

written by
Christos Zoulas.

BUGS

Emulation of signal handlers is buggy.

Emulated connectionless STREAMS fail to receive data from

the network in
some circumstances (but succeed in others -- probably due to

particular
ways of initializing them which the streams(4) module is

mishandling, and
interaction between STREAMS and poll(2)). Connection-ori

ented STREAMS
appear to be functional.

Ironically, this SVR4 emulator does not (yet) support SVR4

semaphores or
shared memory.

ports(7) to automatically create the /compat/svr4 environ

ment do not
exist. tar(1) archives containing pre-populated trees can

be obtained
from http://people.FreeBSD.org/~newton/freebsd-svr4/.

Extensive testing has only really been carried out with So

laris 2.x binaries, with anecdotal reports of limited success coming from

testers with
early-revision SCO media. In theory, the basic SVR4 ABI

should be constant across the set of vendors who produce SVR4 operating

systems, but
in practice that is probably not the case. If necessary,

future work can
either implement additional kld(4) modules which produce

functionality
which contains OS-dependent departures from the behaviour

which has been
implemented in this ABI implementation. Alternatively,

sysctl(8) variables could set the ``personality'' the environment should

present to
client applications.

BSD October 28, 2003

BSD