Партнёры:
Хостинг:
svr4 - System V Release 4 ABI support
options COMPAT_SVR4
Alternatively, to load the ABI as a module at boot time, place the following line in loader.conf5:
svr4_load="YES"
device streamsin a kernel configuration file)
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.
Additionally, some SVR4 operating systems do not adhere to the SVR4
ELF standard.
In particular, Solaris does not set the ELF interpreter 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 executables.
Value ELFOSABI_SOLARIS represents Solaris; ELFOSABI_SYSV represents other
SysVR4 operating systems.
See
#include <sys/elf_common.h>
for ELFOSABI branding definitions, and
brandelf(1)
for information on branding executables.
The module can be linked into the kernel statically with the COMPAT_SVR4 kernel configuration option or loaded as required. 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 kernel loadable module automatically on system startup, see rc.conf5. This information applies regardless of whether the module is statically linked into the kernel or loaded as a module.
STREAMS emulation is limited but (largely) functional. Assuming the streams(4) module is loaded, a STREAMS handle can be obtained by opening one of the relevant files in /dev or /compat/svr4/dev Internally, the streams(4) driver produces a socket descriptor and ``tags'' it with additional STREAMS state information before returning it to the client application. The environment uses the additional state information 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.
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-oriented 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 environment 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 Solaris 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.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |