|
|
Two constants defined in unistd.h for deriving the amode argument are not normally used on SCO OpenServer (EX_OK and EFF_ONLY_OK). SCO OpenServer binaries won't normally use these values since they didn't have kernel support, but since they are in unistd.h, it is possible for an SCO OpenServer application to use them. If such a binary runs on UnixWare 7, the EX_OK and EFF_ONLY_OK constants will be evaluated correctly as part of amode. This may be different than the SCO OpenServer behavior.
Two constants defined in unistd.h for deriving the amode argument are not normally used on SCO OpenServer (EX_OK and EFF_ONLY_OK). Application built using the UnixWare and OpenServer Development Kit and using these flags will run correctly on SCO OpenServer with the Binary Compatibility Module installed.
The SCO OpenServer version of this system call is affected by a number of system tunable parameters that are not present on UnixWare 7 (or SCO UnixWare 2.1.X): update_rtc (if set to 1, the real time clock is set to the new system time after adjtime); clock_drift (the rate at which adjustment is made in nanoseconds/second; and, track_rtc (keeps system clock accurate).
SCO OpenServer applications that make assumptions based on the behavior of adjtime when the above parameters are set (on SCO OpenServer) may exhibit unexpected behavior on UnixWare 7.
The OS libc code retries up to 5 time on an ETXTBSY for execvp and execlp. The SCO UnixWare 2.1.X and UnixWare 7 kernels don't return ETXTBSY so someone expecting this behavior won't see it.
The SCO UnixWare 2.1.X and UnixWare 7 kernels don't return ETXTBSY; the SCO OpenServer kernel does return ETXTBSY, and the code retries up to 5 time on an ETXTBSY for execvp and execlp. To run properly on SCO OpenServer, a UnixWare 7-compiled binary should test for ETXTBSY.
The OS libc code retries up to 5 time on an ETXTBSY for execvp and execlp. The SCO UnixWare 2.1.X and UnixWare 7 kernels don't return ETXTBSY so someone expecting this behavior won't see it.
The SCO UnixWare 2.1.X and UnixWare 7 don't return ETXTBSY; the SCO OpenServer kernel does return ETXTBSY, and the code retries up to 5 time on an ETXTBSY for execvp and execlp. To run properly on SCO OpenServer a UnixWare 7-compiled binary should test for ETXTBSY.
The UnixWare 7 and SCO UnixWare 2.1.X system calls have many more commands than the SCO OpenServer system call: F_DUP2, F_GETOWN, F_SETOWN, F_FREESP, F_RSETLK, F_RSETLKW, F_RGETLK. A portable application compiled on UnixWare 7 should avoid using these commands, as they will fail with ENOSYS (or SIGSYS) on SCO OpenServer.
On SCO OpenServer, these calls behave exactly the same as fork(2).
On SCO OpenServer, the mnemonic for resource number 6 is RLIMIT_AS. On UnixWare 7 and SCO UnixWare 2.1.X, the mnemonic is RLIMIT_VMEM. However, the function of resource number 6 in both systems is exactly the same, so this does not cause a problem for SCO OpenServer binaries on UnixWare 7. Any source code brought to UnixWare 7 from SCO OpenServer would have to be changed (if it uses the SCO OpenServer RLIMIT_AS mnemonic) before compiling with the UnixWare 7 compilation system.
On SCO OpenServer, the mnemonic for resource number 6 is RLIMIT_AS. On UnixWare 7 and SCO UnixWare 2.1.X, the mnemonic is RLIMIT_VMEM. The function of resource number 6 in both systems is exactly the same, so this does not cause a problem for UnixWare 7 binaries run on SCO OpenServer. Any source code brought to SCO OpenServer from UnixWare 7 would have to be changed (if it uses the SCO UnixWare 2.1.X RLIMIT_VMEM mnemonic) before compiling with the SCO OpenServer compilation system.
These SCO OpenServer calls support static shared libraries for user applications; the calls are in the SCO OpenServer kernel, but are not documented. These calls are not supported on either UnixWare 7 or SCO UnixWare 2.1.X. A SCO OpenServer application using this call on UnixWare 7 will return ENOSYS for the call.
Although memcntl isn't documented in SCO OpenServer, there is code in the kernel to support it. The call is documented on UnixWare 7 and SCO UnixWare 2.1.X, and is the same except for two extra subcommands available on SCO OpenServer: MC_MAPCPU and MC_MAPUBLK.
Any SCO OpenServer binary that uses these subcommands will fail with ENOSYS when run on UnixWare 7.
The SCO OpenServer mmap.h contains 4 undocumented subcommands not supported on either SCO UnixWare 2.1.X and UnixWare 7: MAP_PHMEM, MAP_KVMEM, MAP_ANCESTRAL, and MAP_NOEOF. An SCO OpenServer-compiled application will get an ENOSYS error return when it attempts to use these subcommands on UnixWare 7.
File-system specific options can be aproblem if a given fstype name is the same on both systems (in sysfs) but the options in data_ptr are not.
There is a difference in the mflags=0x8 defined in mount.h. On SCO OpenServer it is 'MS_CACHE', described in mount.h as "RFS client caching". On UnixWare it is 'MS_HADBAD', described in mount.h as "file system incurred a bad block so set sstate to FSBADBLK on mount".
The MS_NOEXEC mflag is defined in mount.h on SCO OpenServer as "return ENOEXEC on exec()". Its bit value is 0x8000. UnixWare doesn't have anything at that bit value or a function like this at another value. Using this call on UnixWare results in EINVAL.
File-system specific options can be aproblem if a given fstype name is the same on both systems (in sysfs) but the options in data_ptr are not.
There is a difference in the mflags=0x8 defined in mount.h. On SCO OpenServer it is 'MS_CACHE', described in mount.h as "RFS client caching". On UnixWare it is 'MS_HADBAD', described in mount.h as "file system incurred a bad block so set sstate to FSBADBLK on mount".
The MS_NOEXEC mflag is defined in mount.h on SCO OpenServer as "return ENOEXEC on exec()". Its bit value is 0x8000. UnixWare doesn't have anything at that bit value or a function like this at another value. Using this call on UnixWare results in EINVAL.
The MS_SOFTMOUNT(0x80) and MS_SYSSPACE(0x800) flags are defined in mount.h on SCO UnixWare 2.1.X there are no corresponding hex values in SCO OpenServer mount.h.
On SCO UnixWare 2.1.X and UnixWare 7, nice can only work on processes in the time sharing class, and returns EINVAL on attempts to change the priority of a fixed priority class process. On SCO OpenServer, nice does not return EINVAL. If an SCO OpenServer application is run on UnixWare 7 and does a nice on a fixed priority class process, it would get an unexpected EINVAL error.
To fix, alter the SCO OpenServer application source code to expect EINVAL as a possible error return on using nice, and then recompile.
On SCO UnixWare 2.1.X and UnixWare 7, nice can only work on processes in the time sharing class, and returns EINVAL on attempts to change the priority of a fixed priority class process. On SCO OpenServer, nice does not return EINVAL.
UnixWare 7 applications targeted for SCO OpenServer should not depend on the return of EINVAL.
This SCO OpenServer system call is unsupported on both SCO UnixWare 2.1.X and UnixWare 7.
The paccess(S) system call on SCO OpenServer gets and sets parameters in the u area of the current process and is used by a parent process to trace a child process.
An SCO OpenServer application using paccess must be recoded to use the /proc file system to access status information about a process. See proc(4).
On SCO UnixWare 2.1.X and UnixWare 7, pipes are implemented as two bidirectional, STREAMs-based file descriptors. On SCO OpenServer, a pipe is implemented as two one-way file descriptors, with one fd being 'send' and the other 'receive'. An application compiled using the UnixWare and OpenServer Development Kit and run on SCO OpenServer should not depend on the pipe file descriptors being bidirectional, or it will fail.
The SCO OpenServer poll code shows a system wide tunable poll_delay_compatibility that effects whether a poll call with no file descriptors will honor the timeout; if the tunable is set, the timeout is honored.
SCO OpenServer binaries executed on UnixWare 7 will behave the same as on SCO OpenServer (i.e., the poll_delay_compatibility tunable is checked and the timeout is honored only if the tunable is set). This behavior occurs only for SCO OpenServer binaries (see ``Executable formats'').
On SCO UnixWare 2.1.X, the poll_delay_compatibility tunable is unsupported (see ``poll(2) binary compatibility notes'') and all poll calls, even those with no file descriptors, honor the timeout.
UnixWare 7 supports a few documented commands not supported on SCO OpenServer: PC_ADMIN, PC_SETAGEPARMS, and PC_GETAGEPARMS. A UnixWare 7-compiled application will get an ENOSYS error return when it attempts to use these subcommands on SCO OpenServer.
On SCO OpenServer, this undocumented system call executes all the configured probe routines and returns the information they return to the calling user process. This system call is unsupported on both SCO UnixWare 2.1.X and UnixWare 7. SCO OpenServer applications run on UnixWare 7 will return ENOSYS if they make a call to probe.
An SCO OpenServer application using ptrace should be recoded to use the /proc file system, which is the preferred UnixWare interface for accessing status information about a process. See proc(4).
While ptrace(2) is supported on SCO UnixWare 2.1.X and UnixWare 7, only requests '0' through '9' are supported. The SCO OpenServer kernel supports '0' through '13'.
In order to run on UnixWare, an SCO OpenServer application that needs to use ptrace would probably need to be recompiled using the UnixWare and OpenServer Development Kit. It is highly recommended that such an application be rewritten to use /proc instead.
Since the UnixWare 7 debugger is supported on SCO OpenServer, UDK-produced binaries can use UnixWare 7-style child tracing on SCO OpenServer.
SCO OpenServer applications executing on UnixWare 7 (or SCO UnixWare 2.1.X) will return ENOSYS when using this call and its subcommands. UnixWare 7 equivalents should be used instead, as follows:
| Security subcommand | UnixWare 7 equivalent |
|---|---|
| stopio | |
| getluid | getuid(2) |
| setluid | setuid(2) |
| statpriv | filepriv(2) |
| chpriv | filepriv(2) |
There are differences in the ucontext structure used by this system call on UnixWare 7 and SCO OpenServer:
sigset_t is 4 ints; there is a
uc_privatedatap long and 4
longs of filler at the end of ucontext_t.
sigset_t is 1 int, but there are 3
ints of filler.
At the end of ucontext_t there are 5 longs.
This incompatibility is managed by the UnixWare 7 kernel for SCO OpenServer applications provided these applications always preceed a call to setcontext with a call to getcontext. If an SCO OpenServer-compiled application running on UnixWare 7 (or SCO UnixWare 2.1.X) makes a call to setcontext that is not preceded by a call to getcontext, the application could pass bad data tosetcontext, with unpredictable results.
SCO UnixWare 2.1.X dropped support for statfs. Although the code remains preserved for compatibility in SCO UnixWare 2.1.X and UnixWare 7, there is no manual page and support for this call may be dropped in the future. Recompiled applications should use statvfs(2) instead.
On SCO OpenServer, the SI86GETFEATURES call is used extensively by libc and other libs to determine if a feature is available in the kernel. This subcommand is supported on UnixWare 7. On UnixWare 7, however, FEATURE_TCGETS and FEATURE_SID will be turned off, as these services are not provided by the UnixWare 7 kernel (they are provided by the SCO OpenServer kernel).
There are a number of sysi86 subcommands that are on SCO OpenServer but not on UnixWare 7 or SCO UnixWare 2.1.X. If an SCO OpenServer executable invokes any of these subcommands, the UnixWare 7 kernel returns EINVAL:
The following commands are not supported on SCO OpenServer, and a UnixWare and OpenServer Development Kit-compiled binary will get ENOSYS if it attempts to use these commands on SCO OpenServer:
SI_SET_HOSTNAME SI_HW_PROVIDER SI_HW_SERIAL SI_ARCHITECTURE SI_INITTAB_NAME
The following commands are not supported on both SCO OpenServer and SCO UnixWare 2.1.X:
SI_BUSTYPES SI_KERNEL_STAMP SI_OS_BASE SI_OS_PROVIDER SI_USER_LIMIT
This SCO OpenServer system call and the kernel tunables it provides are unsupported on both SCO UnixWare 2.1.X and UnixWare 7.
The SCO OpenServer syssetconf system call is an extension to sysconf that provides a set of 'kernel' type tunables, none of which are documented on the SCO OpenServer sysconf(S) man page (syssetconf itself is undocumented on SCO OpenServer). These constants are visible to applications, however, in the &osr ``sys/unistd.h.'' header file, so an SCO OpenServer application may use them. None of these values are defined on SCO UnixWare 2.1.X or UnixWare 7. SCO OpenServer applications run on UnixWare 7 that use syssetconf on UnixWare 7 will return ENOSYS (and/or a SIGSYS signal). Such applications need to be recoded to work properly on UnixWare 7.
Note that in UnixWare 7 (and SCO UnixWare 2.1.X), sysconf(3C) is implemented as a C library function, not a system call.
There are two commands for this system call on SCO OpenServer that are unsupported opn UnixWare 7 and SCO UnixWare 2.1.X: A_BDEVSYNC, A_GETDEV, and AD_PWRNAP. SCO OpenServer applications using these commands on UnixWare 7 will get an ENOSYS error return and a SIGSYS signal).
On UnixWare 7 and SCO UnixWare 2.1.X, the AD_HALT subcommand (to A_SHUTDOWN) shuts the system down, but does not support the "reboot on keystroke" functionality supported by SCO OpenServer.
UnixWare 7 applications executing on SCO OpenServer and using the AD_HALT subcommand (to A_SHUTDOWN) will get the "reboot on keystroke" functionality as well as shutting the system down (there is no "reboot on keystroke" on UnixWare 7 and SCO UnixWare 2.1.X). The AD_PWRDOWN command, supported on UnixWare 7 and SCO OpenServer only, shuts the system down on both systems with no reboot option.
The UnixWare 7 and SCO UnixWare 2.1.X system call support two more commands than SCO OpenServer: UL_GMEMLIM and UL_GDESLIM. A portable application compiled on UnixWare 7 should avoid using these commands, as they will fail with ENOSYS (or SIGSYS) on SCO OpenServer.
The SCO OpenServer xsetregid(S) and xsetreuid(S) functions allow setting the 'real' and 'effective' uids and gids in one system call. There are versions supported on SCO OpenServer in both libc.so.1 and libsocket.a. SCO OpenServer applications must have been compiled using the version in libc.so.1 in order to run on UnixWare 7 (applications linked with static archives are unsupported on UnixWare 7).
When an SCO OpenServer application using these calls is run on UnixWare 7,
these calls are mapped to the
setreuid(3C)
and
setregid(3C)
functions.