Movatterモバイル変換


[0]ホーム

URL:


Skip to main content.

Navigation:

NetBSD Binary Emulation

Binary Emulation


Binary Emulation

What is Binary Emulation? Why does it exist?

A large amount of Unix software is distributed in source-code format.This means the authors actually provide the programcode, and the installation process uses a compiler to generate an executableto run on the local machine. Carefully written source-code and installationutilities can allow the same program to be built on dozens of differentoperating systems.

Commercial software vendors are not inclined to distribute source codesince it may contain trade secrets. Commercial vendors normally deliverthe executable programs which can be run directly. They perform the compilationstage in-house, and delivery binary files from which their secrets areless easily discernible.

The result of this is that the vendor must make a choice to expend man-powerfor each different operating system they support, normally maintaininga system to do testing with, and at least one person to do compilationand testing.

This ties together the Operating System and the set of applicationsa consumer may wish to run. One may choose not to run a particular applicationbecause it is not available on their Operating System of choice, or onemay be forced to run an Operating System one would rather not, due to theavailability of some critical application.

Binary Emulation eliminates this forced linkage.

How does it work?

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 throughkernel system calls. An example would be a program requesting to OPEN afile, the program calls the kernel OPEN function with a set of parametersindicating what it wishes to do, and the kernel allows or denies the request,and replies with the information the program requires to continue.

Every Unix and Unix-like system supplies a very similar set of thesesystem calls. They all have an OPEN for example.

From system to system, the primary differences in syscalls will be inthe format of parameters passed to these calls. The names of the calls mayalso differfrom 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 mappingfunction to the corresponding NetBSD system call, and re-orders/re-formatsthe parameters as required.

Another important issue is the format of the executable files.About every second operating system uses a different file format in which itsaves its binaries, using different headers, magic cookies, hunks, whatever.The ones NetBSD supports natively are ELF and a.out. NetBSD'semulation knows how to handle the executable format for the emulated system.

The final significant requirement is that the CPU the executable wascompiled for must match the system it will run on. Besides system calls,executables consist of raw CPU instructions.

How well does it perform?

Since the only additional overhead is the mapping from emulated system callsto native NetBSD system calls, and the reformatting of any parameters,if needed, the performance is really, really good. A rough estimate wouldbe at most a 1-2% performance impact. Thisvaries depending on which system calls a program uses. Most mappings take<1% of the time the actual syscall takes to run.

Any other considerations?

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 functionscompiled in, but it requires an externalset of libraries which must match the ones the program was compiled touse (not including minor modifications). If you wish to run a programunder binary emulation, you can check whether it was statically or dynamicallylinked, by using the 'file' command...

% file qwsvqwsv: BSD/OS i386 compact demand paged executable% file arparp: NetBSD/i386 demand paged dynamically linked executable

The presence of 'dynamically linked' indicates exactly that, its absenceindicates static linking. Shared object libraries for most freely availableUnix systems are available from the NetBSD pkgsrc, under the /compat directory.Note that these shared library sets are _not required_ if you are onlygoing to run statically linked binaries.

For commercial systems, you may need to supply your own set of libraries.Seeman -k compat for a list, andman compat_os(whereos is the target OS) for some installation instructions:

% man -k compatcompat_linux(8) - setup procedure for running Linux binariescompat_sunos(8) - setup procedure for m68k and sparc architecturescompat_ultrix(8) - setup procedure for Ultrix compatibility on mips and vax

Which OSs can I emulate on my machine?

NetBSD supports emulation of several systems. Generally speaking, you canrun binaries from other unix operating systems which run on the samehardware as your NetBSD system.

aarch64
  • Linux 64bit
  • Linux 32bit
  • NetBSD 32bit
alpha
  • Linux (Alpha)
amd64
  • Linux 64bit
  • Linux 32bit
  • NetBSD 32bit
amiga
  • Linux (m68k)
  • SunOS (68k)
atari
  • Linux (m68k)
  • SunOS (68k)
hp300
  • Linux (m68k)
  • SunOS (68k)
i386
  • Linux 32bit
mac68k
  • Linux (m68k)
  • SunOS (68k)
mvme68k
  • Linux (m68k)
  • SunOS (68k)
news68k
  • Linux (m68k)
  • SunOS (68k)
next68k
  • Linux (m68k)
  • SunOS (68k)
sgimips
  • Linux (mips)
  • Ultrix (mips)
sparc
  • SunOS (sparc)
sparc64
  • 32-bit NetBSD/sparc (both ELF and a.out)
  • SunOS (sparc)
sun3
  • Linux (m68k)
  • SunOS (68k)
vax
  • Ultrix
x68k
  • Linux (m68k)
  • SunOS (68k)

Back to  NetBSD Documentation
Contact | Disclaimer |Copyright © 1994-2025 The NetBSD Foundation, Inc.ALL RIGHTS RESERVED.
NetBSD® is a registered trademark of The NetBSDFoundation, Inc.

[8]ページ先頭

©2009-2025 Movatter.jp