STLLUG - St. Louis Linux User Group
08/17/1995 : Linux Frontiers
Presenter: Matthew Feldt
Linux Frontiers
Matt Welsh
O'Reilly and Associates, Inc.
What is Linux?
- Free 32-bit UNIX system for the x86
- Developed by volunteers on Internet
- Distributed via FTP and CD-ROM by many vendors
- Supports full preemptive multitasking, TCP/IP networking, and much more
- Large hardware support base
- Thousands of free applications available: X11R6, Emacs, TeX, gcc, you name it
- Commercial apps emerging including WordPerfect and Mathematica
- Being ported to Alpha, m68k, SPARC, MIPS, and others
More Information about Linux
Overview
- ELF Support
- Executable and Linkable Format: AT&T Binary Spec for Linux
- iBCS2 Emulation
- The standard for x86 UNIX binaries
- WINE: The Windows Emulator
- Run MS-Windows applications under Linux/X11R6
- Loadable Kernel Modules
- Load and unload kernel drivers dynamically
ELF
- Executable and Linkable Format
- Defines binary format for executables, object files, and libraries.
- a.out and COFF
- Two other binary formats: a.out originated at BSD, and used initially by Linux.
- Advantages of ELF
- More flexible and powerful than a.out, simplifies compilers
and linkers. Also more complex, and more processing overhead is
required in some cases.
- Makes it very easy to build and use shared libraries.
- More interoperable with other systems and tools.
ELF vs. a.out format
Building ELF Shared Libraries
- Build objects as PIC (position-independent) code:
gcc -fPIC -O -c foo.c -o foo.o
- Link objects into shared object:
gcc -shared -o libfoo.so foo.o bar.o ...
- To use shared libs, just link as normal:
gcc -O -o baz baz.o -lfoo
Uses libfoo.so shared lib automatically.
Dynamic Linking and Loading
- ld.so
- performs dynamic linking for executables at load time
- libdl.a
- allows you to do dynamic linking within a program
* dlopen() opens shared object, returns handle
* dlsym() looks up symbol from shared object, returns pointer
Can then use pointer (function or object) as usual
Dynamic Linking Example
/* Open shared obj libfoo.so
* RTLD_LAZY: Only relocate as necessary
*/
handle = dlopen( "libfoo.so", RTLD_LAZY );
/* Look up symbol for thefunction() */
funcptr = ( funcptr_t )dlsym( handle, "thefunction" );
/* Call function from shared object */
( *fptr )();
Dynamic linking with ELF is easy and fun!
Upgrading to ELF
All tools at ftp://sunsite.unc.edu/pub/Linux/GCC
You will need:
- Post-1.1.52 kernel
- ld.so-1.7.3.tar.gz -- new runtime linker
- libc-5.0.9 -- new ELF-based C library
- gcc-2.7.0 -- gcc with ELF support
- binutils-2.6.2.l17 -- ld, gas, etc. for ELF
- The Linux ELF-HOWTO -- a must!
iBCS2 Support
Intel Binary Compatibility Spec, v.2
- Standard for user/kernel interface for x86 UNIX systems,
including SVR3, SVR4, BSD, Xenix, etc.
- Defines system call interface, signal behavior, network
layer interface, etc.
- Nothings perfect: Many vendor-specific extensions
iBCS2 for Linux
- Allows binaries from other x86 UNIX systems to run under Linux
- This includes commercial applications!
iBCS2 Features
Kernel emulator
- Loads binaries of appropriate format (ELF, COFF, etc.)
- Provides LCALL7 trap for system calls
Personalities
- Each process has a "personality" chosen from binary format
at load time
- Maps system calls, error codes, and signal numbers between
application and kernel
- Also used to choose system-call behavior on per-process
basis (e.g., select timeout)
iBCS2 Shared libraries
- Dynamically-linked binaries need an iBCS2-compliant libc.so
- iBCS2 team has modified libc sources for this
- Statically-linked binaries (e.g., WordPerfect) have no problem
- XFree86 shared libraries can be used for X apps
- libsocket, libnsl used by some systems has limited support
- You may be able to use native shared libs under Linux (with
ELF support) if license permits
Supported Systems
Binary formats
- a.out, ELF, COFF, or x.out
O/S emulations
- i386 BSD (386BSD, FreeBSD, NetBSD, BSDI/386), very alpha.
- SVR4 (Interactive, Unixware, USL, Dell etc.)
- SVR3 generic
- SCO (SVR3 with extensions for symlinks and long filenames)
- Wyse V/386 (SVR3 with extensions for symlinks)
- Xenix V/386 (386 small model binaries only)
- Xenix 286
Getting the Emulator
Files at
tsx-11.mit.edu/pub/linux/BETA/ibcs2
- ibcs-1.2-yymmdd.tar.gz
- The kernel emulator
- sco-libs-yymmdd.tar.gz
- SCO shared libs
- svr4-shlib-yymmdd.tar.gz
- SVR4 shared libs
- libc_s-yymmdd.tar.gz
- iBCS2 libc source
Mail majordomo@vger.rutgers.edu for info on the linux-ibcs2
mailing list
WINE: The Windows Emulator
What is it?
- An MS-Windows emulator for x86-based UNIX and X11
- Loads MS-Windows executables into 32-bit UNIX process
- Emulates Windows API by catching calls and translating to X11 equivalents
How well does it work?
- Most applets installed with Windows run to some extent
- Solitaire works!
- A number of PD/shareware MSW games run
- No reports of major apps yet---except occasionally Quicken
Where can I get WINE?
- /pub/Linux/ALPHA/wine on sunsite.unc.edu
- Most recent is Wine-yymmdd.tar.gz
- First get the Wine.FAQ and related docs
- See comp.emulators.ms-windows.wine
WINE Program Loader
- Loads MS-Windows .EXE file into 32-bit process address space
- All WINE code itself is 32-bit, but this is fine
- No need for machine-level emulation
- Loads executable and each WINE module, performing relocation
for API entry points
- Creates x86 selector for each module segment
- Adds selectors to process LDT with new system call: modify_ldt
- Kernel creates new LDT for process, copies it, and adds new selectors
WINE Windows API Emulator
- Loader provides 16-bit entry points for all API functions
- Stack frame is copied on API call and control transfered to
32-bit WINE function
- WINE code produces X11 calls when appropriate, and captures X events
Loadable Kernel Modules
Dynamically loaded kernel code
- Allows device drivers, file systems, or other routines to be
contained in a module
- Modules can be loaded and unloaded on a running system
- Saves memory and kernel image size; only load those modules you need
- Allows portions of kernel to be maintained and released independently
What is a module?
- Simply an object file containing routines and/or data to load
into a running kernel
- If multiple source files are used, prelink into one .o file with ld -r
- Must provide two routines (init_module and cleanup_module) called
at module load/unload
Required Tools
- A recent 1.2.x or 1.3.x kernel
- Module utilities insmod, lsmod, and rmmod (found with kernel source)
Loading a Module
- Prepare module in user space
- insmod reads object file from disk, resolve any external symbols
- These symbols provided by kernel or other loaded modules using get_kernel_syms
- This is similar to linking an object against other objects
- Allocate kernel memory
- create_module() tells kernel to alloc memory for new module
- Takes two args: name of module and total size
- Load module into kernel memory
- init_module() called to copy module into kernel space
- insmod must also pass in module name, size, pointers to init/cleanup, etc.
- Add exported module symbols to kernel
- Symbol table passed in by init_module added to kernel's list
- Module symbols can now be used by other modules --- "stacking"
- Modules can shadow each other's symbols
- Call init_module routine
- Module now part of kernel proper; just fire it up
Module Dependencies and Deletion
Deleting a module
- Kernel keeps list of module dependencies
- Can't delete a module if any other module uses routines from it
- If ref count is 0, cleanup_module called, and kernel memory freed
Dependencies
- Modules can only be loaded into kernel they were compiled under
- This prevents data structures, function interfaces, etc. from differing
- Can cause serious and subtle problems if this is not adhered to!
- New features allow modules to keep track of struct "versions"
- Checksum computed for each data structure used in kernel and module
These are slides for the "Linux Frontiers" talk given for the
O'Reilly and Associates "Running Linux '95" tour. For more information
please contact Matt Welsh at mdw@cs.cornell.edu.
This file and associated slides are Copyright (c)1995 by Matt Welsh.
You are free to copy and distribute this file (or slides produced thereof)
VERBATIM in any medium, physical or electronic. This copyright notice
should be entact on all copies and attribution to the author retained.
Update: mdw 21 August 1995
Links and conversion from Postscript to HTML done by Matthew Feldt.
Last Modified: 5 September 1995
St. Louis Unix Users Group - Linux SIG