What it is ========== This is a project that Sean Eric Fagan (sef@kithrup.com) started, and Soren Schmidt (sos@login.dknet.dk, author of syscons) picked up. It allows SYSVr3.2 i386 binaries (iBCS2 compatible) to run under FreeBSD-2.0. We haven't been able to do an exhaustive test, of course, but we are able to run at least the following programs: ISC 2.2 sh, vi, dd, date, wc, chmod, etc. SCO 3.2v2 runs most (coff) utils on a chroot'ed filesystem Informix-2.10, gcc, bash, tcsh .... SCO 3.2v4 sh, gzip, GNU make, tcsh Some of those, for both ISC and SCO, used the shared libraries that are available for those systems. Currently, the only way to run them, is to get a copy of the shared libraries in question (e.g. /shlib/libc_s). There might be a way to generate them from a package available for Linux, but we haven't had the time or energy to do it ourself, and the last call for volunteers resulted in nothing. If someone else wants to volunteer, we would be grateful. How to get it into the system ============================= There are two ways of getting iBCS2 support into the system. One is to use Loadable Kernel Modules (LKM) to put it into the kernel at run-time. This demands a kernel compiled with: options "COMPAT_IBCS2" This puts in the nessesary hooks to let the iBCS2 support do its thing. One loads the iBCS2 support by using the command 'ibcs2' (in /usr/bin). You can use 'modstat' to see the loaded modules. Another way is to compile it into the kernel. This is accomplished using: options "COMPAT_IBCS2" options "IBCS2" in the kernel config file. Where's what ============ The ibcs2 package consists of quite a few files located in ./sys/i386/ibcs2. Here is a brief description of them: ibcs2.h: Basic header file defines iBCS2 types etc. ibcs2_dummy.c: Stubs to system calls not yet supported, or not feasible to emulate. ibcs2_ioctl.c: Probably the single-most complicated part of it, this deals with translating as many ioctl calls as possible between BSD and iBCS2. ibcs2_misc.c: This has all of the wrapping routines that were thought "easy" (at least initially) or that didn't fit anywhere else. ibcs2_file.c: Functions that deals with file I/O, such as getdents and read which are more complex than one should expect. ibcs2_signal.c: This deals with the signal cruft, including both system calls and signal translation. ibcs2_stats.c: This has all of the filesystem statistic wrappers (stat, fstat, statfs, etc.). ibcs2_sysent.c: This has the system call table for iBCS2 programs, and is NOT generated automatically. ibcs2_ipc.c: Stubs for the iBCS2 ipc calls (shm, msg, sem). ibcs2_isc.c: This deals with the ISC specific system call (cisc()). ibcs2_sysi86.c: This deals with the i86 specific system call (sysi86()). ibcs2_xenix.c: This deals with the Xenix specific system call (cxenix()). (This also has some of SCO's POSIX-conformant functions.) imgact_coff.c: This is the functions that alllows the kernel to load COFF programs. It also deals with shared library loading. There also exist two files (ibcs2_socksys.[ch]) which contains a proto implementation of the SYSVr3 socket system, donated by Mostyn Lewis (mostyn@mrl.com). It has not been tested much but is included as a basis for network support, which is nessesary to run X and the likes. What's Next =========== Much needs to be done yet, mainly the socksys emulation should be looked at to get socket support going. There currently also is no ipc support. The sem & msg functions should map fairly easy to the BSD ones, but our current BSD shm implementation is not even close to SYSV behavior, if it works at all. We currently have loaders or "image_activators" for other binary formats, but none of them is really usefull yet (xout, elf). Also most of the wrappers for the extra syscalls used by SYSVr4 has been done, but not much testing yet because of lacks in the elf loader (but it will run a statically linked SYSVr4 shell). All the wrappers should be tested one by one using every aspect of use by the iBCS2 system. The tests we have done so far is to run small testprograms to check a limited set of the emulation. When this proved that the basics was functional, we tried with what iBCS2 programs where at hand. This is by no means an exhaustive test or to say that the emulation is errorfree, only a statement of overall functionality of the emulator. Surely much work can be done here, but we are both kind of lazy, and did the whole thing just for the fun of it, and mainly as a "can it be done" project. Soren Schmidt (sos@login.dknet.dk) Sean Eric Fagan (sef@kithrup.com)