[BACK]Return to compat.xml CVS log [TXT][DIR] Up to [cvs.NetBSD.org] / htdocs / docs

File: [cvs.NetBSD.org] / htdocs / docs / compat.xml (download)

Revision 1.11, Sun Nov 1 18:41:47 2020 UTC (11 months, 2 weeks ago) by nia
Branch: MAIN
CVS Tags: HEAD
Changes since 1.10: +3 -36 lines

remove reference to obsolete compats and excess wordiness

<?xml version="1.0"?>
<!DOCTYPE webpage
  PUBLIC "-//NetBSD//DTD Website-based NetBSD Extension//EN"
    "http://www.NetBSD.org/XML/htdocs/lang/share/xml/website-netbsd.dtd">

<webpage id="docs-compat">
<config param="desc" value="NetBSD Binary Emulation"/>
<config param="cvstag" value="$NetBSD: compat.xml,v 1.11 2020/11/01 18:41:47 nia Exp $"/>
<config param="rcsdate" value="$Date: 2020/11/01 18:41:47 $"/>
<head>

<!-- Copyright (c) 2000-2006
        The NetBSD Foundation, Inc.  ALL RIGHTS RESERVED. -->

<title>NetBSD Binary Emulation</title>
</head>


<sect1 role="toc">

<sect2 id="binary-emulation">
<title>Binary Emulation</title>

<sect3 id="what">
<title>What is Binary Emulation? Why does it exist?</title>
<para>
A large amount of Unix software is distributed in source-code format.
This means the authors actually provide the program
code, and the installation process uses a compiler to generate an executable
to run on the local machine. Carefully written source-code and installation
utilities can allow the same program to be built on dozens of different
operating systems.
</para>
<para>Commercial software vendors are not inclined to distribute source code
since it may contain trade secrets. Commercial vendors normally deliver
the executable programs which can be run directly. They perform the compilation
stage in-house, and delivery binary files from which their secrets are
less easily discernible.
</para>
<para>The result of this is that the vendor must make a choice to expend man-power
for each different operating system they support, normally maintaining
a system to do testing with, and at least one person to do compilation
and testing.
</para>
<para>This ties together the Operating System and the set of applications
a consumer may wish to run. One may choose not to run a particular application
because it is not available on their Operating System of choice, or one
may be forced to run an Operating System one would rather not, due to the
availability of some critical application.
</para>
<para>Binary Emulation eliminates this forced linkage.
</para>
</sect3>

<sect3 id="how">
<title>How does it work?</title>
<para>
Unix and Unix-like systems consist of two primary parts, the Kernel,
and everything else. The kernel is the program which controls devices,
security, and the programs which wish to use the machine's resources.
Typically, the kernel provides these services to other programs through
kernel system calls. An example would be a program requesting to OPEN a
file, the program calls the kernel OPEN function with a set of parameters
indicating what it wishes to do, and the kernel allows or denies the request,
and replies with the information the program requires to continue.
</para>
<para>Every Unix and Unix-like system supplies a very similar set of these
system calls. They all have an OPEN for example.</para>
<para>
From system to system, the primary differences in syscalls will be in
the format of parameters passed to these calls. The names of the calls may
also differ
from system to system. If a NetBSD system wishes to run a Linux executable,
each time the program performs a system call, the kernel performs a mapping
function to the corresponding NetBSD system call, and re-orders/re-formats
the parameters as required.
</para>
<para>Another important issue is the format of the executable files.
About every second operating system uses a different file format in which it
saves its binaries, using different headers, magic cookies, hunks, whatever.
The ones NetBSD supports natively are ELF and a.out. NetBSD's
emulation knows how to handle the executable format for the emulated system. 
</para>
<para>The final significant requirement is that the CPU the executable was
compiled for must match the system it will run on. Besides system calls,
executables consist of raw CPU instructions.
</para>
</sect3>

<sect3 id="performance">
<title>How well does it perform?</title>
<para>
Since the only additional overhead is the mapping from emulated system calls
to native NetBSD system calls, and the reformatting of any parameters,
if needed, the performance is really, really good. A rough estimate would
be at most a 1-2% performance impact.  This
varies depending on which system calls a program uses. Most mappings take
&lt;1% of the time the actual syscall takes to run.
</para>
</sect3>

<sect3 id="considerations">
<title>Any other considerations?</title>
<para>
In addition to the CPU being of the same type, and the mapping of system calls,
there is one other requirement. Many Unix systems support shared libraries.
This means that a compiled program does not come with all of its functions
compiled in, but it requires an external
set of libraries which must match the ones the program was compiled to
use (not including minor modifications). If you wish to run a program
under binary emulation, you can check whether it was statically or dynamically
linked, by using the 'file' command...
</para>

<programlisting>% file qwsv
qwsv: BSD/OS i386 compact demand paged executable
% file arp
arp: NetBSD/i386 demand paged dynamically linked executable</programlisting>

<para>The presence of 'dynamically linked' indicates exactly that, its absence
indicates static linking. Shared object libraries for most freely available
Unix systems are available from the NetBSD pkgsrc, under the /compat directory.
Note that these shared library sets are _not required_ if you are only
going to run statically linked binaries.
</para>
<para>For commercial systems, you may need to supply your own set of libraries.
See <code>man -k compat</code> for a list, and <code>man compat_<emphasis>os</emphasis></code>
(where <emphasis>os</emphasis> is the target OS) for some installation instructions:

<programlisting>% man -k compat
compat_linux(8) - setup procedure for running Linux binaries
compat_sunos(8) - setup procedure for m68k and sparc architectures
compat_ultrix(8) - setup procedure for Ultrix compatibility on mips and vax</programlisting>
</para>
</sect3>

<sect3 id="ports">
<title>Which OSs can I emulate on my machine?</title>
<para>
NetBSD supports emulation of several systems. Generally speaking, you can
run binaries from other unix operating systems which run on the same
hardware as your NetBSD system.
</para>

<sect4 id="emulation-aarch64">
<title>aarch64</title>
	<itemizedlist>
	<listitem>NetBSD 32bit</listitem>
	</itemizedlist>
</sect4>

<sect4 id="emulation-alpha">
<title>alpha</title>
	<itemizedlist>
	<listitem>Linux (Alpha)</listitem>
	</itemizedlist>
</sect4>

<sect4 id="emulation-amd64">
<title>amd64</title>
	<itemizedlist>
	<listitem>Linux 64bit</listitem>
	<listitem>Linux 32bit</listitem>
	<listitem>NetBSD 32bit</listitem>
	</itemizedlist>
</sect4>

<sect4 id="emulation-amiga">
<title>amiga</title>
	<itemizedlist>
	<listitem>Linux (m68k)</listitem>
	<listitem>SunOS (68k)</listitem>
	</itemizedlist>
</sect4>

<sect4 id="emulation-atari">
<title>atari</title>
	<itemizedlist>
	<listitem>Linux (m68k)</listitem>
	<listitem>SunOS (68k)</listitem>
	</itemizedlist>
</sect4>

<sect4 id="emulation-hp300">
<title>hp300</title>
	<itemizedlist>
	<listitem>Linux (m68k)</listitem>
	<listitem>SunOS (68k)</listitem>
	</itemizedlist>
</sect4>

<sect4 id="emulation-i386">
<title>i386</title>
	<itemizedlist>
	<listitem>Linux 32bit</listitem>
	</itemizedlist>
</sect4>

<sect4 id="emulation-mac68k">
<title>mac68k</title>
	<itemizedlist>
	<listitem>Linux (m68k)</listitem>
	<listitem>SunOS (68k)</listitem>
	</itemizedlist>
</sect4>

<sect4 id="emulation-mvme68k">
<title>mvme68k</title>
	<itemizedlist>
	<listitem>Linux (m68k)</listitem>
	<listitem>SunOS (68k)</listitem>
	</itemizedlist>
</sect4>

<sect4 id="emulation-news68k">
<title>news68k</title>
	<itemizedlist>
	<listitem>Linux (m68k)</listitem>
	<listitem>SunOS (68k)</listitem>
	</itemizedlist>
</sect4>

<sect4 id="emulation-next68k">
<title>next68k</title>
	<itemizedlist>
	<listitem>Linux (m68k)</listitem>
	<listitem>SunOS (68k)</listitem>
	</itemizedlist>
</sect4>

<sect4 id="emulation-sgimips">
<title>sgimips</title>
	<itemizedlist>
	<listitem>Linux (mips)</listitem>
	<listitem>Ultrix (mips)</listitem>
	</itemizedlist>
</sect4>

<sect4 id="emulation-sparc">
<title>sparc</title>
	<itemizedlist>
	<listitem>SunOS (sparc)</listitem>
	</itemizedlist>
</sect4>

<sect4 id="emulation-sparc64">
<title>sparc64</title>
	<itemizedlist>
	<listitem>32-bit NetBSD/sparc (both ELF and a.out)</listitem>
	<listitem>SunOS (sparc)</listitem>
	</itemizedlist>
</sect4>

<sect4 id="emulation-sun3">
<title>sun3</title>
	<itemizedlist>
	<listitem>Linux (m68k)</listitem>
	<listitem>SunOS (68k)</listitem>
	</itemizedlist>
</sect4>

<sect4 id="emulation-vax">
<title>vax</title>
	<itemizedlist>
	<listitem>Ultrix</listitem>
	</itemizedlist>
</sect4>

<sect4 id="emulation-x68k">
<title>x68k</title>
	<itemizedlist>
	<listitem>Linux (m68k)</listitem>
	<listitem>SunOS (68k)</listitem>
	</itemizedlist>
</sect4>
</sect3>

</sect2>
</sect1>
<parentsec url="." text="NetBSD Documentation"/>
</webpage>