FMIOSAComparativeStudy » FMIOSAComparativeStudyPartIIUserLand » 

[WARNINGS]
link-id not found - [fmiosacomparativestudypartikernellandchapter1bootup|1
link-id not found - [fmiosacomparativestudypartikernellandchapter3scheduling|3
link-id not found - [fmiosacomparativestudypartikernellandchapter5memorymanagement|5
link-id not found - [fmiosacomparativestudypartikernellandchapter7deadlocks|7
link-id not found - [fmiosacomparativestudypartiiuserlandchapter8iolayers|8
link-id not found - [fmiosacomparativestudypartiiuserlandchapter10environmentlayer|10

Intro (I 1 2 3 4 5 6 7) (II 8 9 10 11) (D) (C) (B

I)

h1. Chapter 10: Environment Layer

("Smith & Wesson - the original point and click interface.")

The Environment Layer of a computer is the final level of abstraction between the computer and the user. The environment is typically customized and geared towards the user's specific activity on the machine. Some are proprietary to the device (such as in embedded systems) and some are designed to meet a standard. Linux is an environment layer meeting the POSIX standard; Windows XP, Windows 2000 and Windows NT are all environment layers that meet the Win32 standard.

h2. 1. Responsibilities

The environment layer has many responsibilities, tying together all of the kernel and user level functionality into a convenient, machine and kernel independent standard interface. This allows a program to run on all of the operating systems that meet that particular standard, regardless of the type of processor or machine it's running on.

For instance, suppose you have one of your old favorite games, "The Incredible Machine," which you ran on Windows 3.1 on an old 3x86 machine many years ago. If you were to slide that disk into a newer computer, running on a Pentium or Athlon chip, with Windows XP, it would still run! When the game was written it used commands that conformed to the Win32 API, or Application Programming Interface, standard. Ancient Windows 3.1 (with the Win32 patch) and the modern Windows XP both conform to that standard. The Win32 environment layer will take the commands from the game, filter them and translate them appropriately on the current Windows kernel version and computer type.

Adhering to this standard isn't just a manner of accepting the appropriate commands from the programs; it's also about providing a user interface. DOS had a command-driven user interface much like UNIX. Windows is a graphical user interface (GUI) much like the MacOS and Linux' X Window System.

During development of FMI/OS, the environment layer of choice is that of a command line POSIX standard.

h2. 2. POSIX

POSIX systems require implementations and accommodations of many different C programming language calls and functionality. This is one of the reasons why they are used frequently by developers and programmers. To achieve this, POSIX systems have libc libraries. These are OS-independent libraries that provide such C commands as @malloc()@ and @fork()@.

User programs very rarely make direct syscalls. Instead, they use higher-level commands (functions) that are part of a library such as the @libc@ library. Programs, shells, and command-line commands can invoke libraries.

Many popular routines found in the libc library are:

  • @termcap@ routines (contain a database of the detailed compatibilities of hundreds of different terminals, which are monitor and keyboard interfaces) http://www.delorie.com/gnu/docs/termcap/termcap_1.html
  • @regexp@ routines (POSIX- standard pattern-matching library, provide commands for searching strings or text for certain patterns) http://en.wikipedia.org/wiki/Regular_expression
  • @curses@ routines (used for coloring, highlighting, moving, etc., text on the screen)
  • @math@ routines (common math routines, such as: @log()@, @sin()@, @sqrt()@, etc.)
  • other miscellaneous helper routines
  • routines that emulate POSIX system calls

The library bundles come in different flavors:

  • "@glibc@":http://www.gnu.org/software/libc/libc.html:
    • GNU C library; most widely used and comes with all Linux distributions
  • "@uClibc@":http://www.uclibc.org/about.html, @newlibc@, @dietlibc@:
    • provides much more compact @libc@s for use in embedded devices.

h2. 3. FMI/OS

FMI/OS's library structure is organized in such a way as to increase flexibility in the environment layer.

  • @libfmi@
    • sits right on the kernel
    • Contains FMI/OS-specific routines for efficient use of kernel functions, such as message-passing and memory management, etc.
    • @msgconnect()@, @msgsend()@, @t_fork()@, etc (see FMIOS Syscall API)
  • @libposix@
    • uses @libfmi@
    • wrapper routines that create POSIX-like interface and syscalls which most @libc@s expect.
    • some POSIX syscalls are wrappers of FMI/OS syscalls, but some (in regards to disk I/O, etc.) are actual wrappers for IPC calls.
    • @read()@, @write()@, @fork()@, etc.
  • @libc@
    • uses @libposix@
    • contains the core C libraries for use by all programs.
    • @math.h@, @pthread.h@, @sched.h@, etc

There are two great advantages for this hierarchy. First, whereas FMI/OS contains General Public Licensed (GPL) code, @libfmi@ is licensed under the Lesser GPL (LGPL) so that non-GPL applications can link to it. (For more GPL information see Chapter11OpenSourceDevelopment). It is essential to not limit the number of programs that can use FMI/OS.

The avoidance of licensing issues is also essential for the 2nd advantage of the library hierarchy: flexibility of environment layers. What this means is that many other environment standards can be implemented other than just POSIX. For instance, a @libwine@ library can be created to create a Win32 environment, thus allowing Windows to run on an FMI/OS kernel.

(c)2006 Dimitri Hammond

AddComment

Also available in: HTML TXT