Glibc Architecture Overview

Depicted in example 2.1 is a diagram that is all too familiar to anyone who has studied CS101¹. It stretches the metaphor of `a nut' somewhat: the user interacts with the shell, which calls applications on the user's behalf, where the applications in turn call upon services tendered by the kernel.

          ,------------------.
          |    ,--------.    |
          | ,--| UNIX   |--. |
          | |  | Kernel |  | |
          | |  `--------'  | |  User
          | | Applications | |
          | `--------------' |
          |      Shell       |
          `------------------'
          

     Example 2.1: Simplified system architecture component relationships
     

Traditionally, the shell is represented by the command line interface that the user manipulates to control their machine - effectively your login shell, probably /bin/bash, on a GNU/Linux system; or even DOS on a Windows machine. In reality graphical user shells are rife in modern computing, and much of the work of a traditionalist's shell is performed graphically. If you have GNU/Linux, then you almost certainly use either the GNOME or KDE desktops as your shell. Alternatively, if you use a Microsoft system, you might have noticed that DOS has been superceded by Windows as the dominant user shell in recent years...

At the centre of any `nut' is, of course, a kernel. Again, on a GNU/Linux system, the metaphorical nut that is your computer system might have Linux as its kernel, or as another example: BSD UNIX if you run Mac OS X. Each of the many flavours of Windows also contain a kernel, but it is harder to draw a dividing line between shell and kernel in this case, since the Windows kernel provides both system services and graphical desktop management.

The applications are the flesh of our `nut', and thus lie between the kernel, which controls the hardware in your computer, and the shell, which you interact with. Traditionally, an application accepts input text from a keyboard, and displays output text to a monitor screen. These days, applications tend to come with more sophistacted interfaces, and could accept input from a variety of devices: a mouse, a stylus or a scanner for instance. Equally, the output from an application likely involves not only displaying high resolution graphics on the monitor screen, but maybe also output to, among others, an LED display or a network interface card. The shell is itself really just another application that is specialised for helping a user to control and receive responses from other applications.

           .------------------.
           |   ,-------.      |
           |   | Glibc |      |
           |   | ,--------.   |
           | ,-| | UNIX   |-. |
           | | | | Kernel | | |  User
           | | | `--------' | |
           | | `-------'    | |
           | | Applications | |
           | `--------------' |
           |      Shell       |
           `------------------'
          

     Example 2.2: Simplified component relationships with glibc
     

Here, in example 2.2 we show where glibc fits in to all of this. Fundamentally, it provides a higher level API for interacting with the machine than the low level system calls implemented by the kernel. But more importantly than that, it supplies a standard interface to many of the common facilities used by the applications. It would be perfectly possible to write an application that does not use glibc, but implements everything from first principles in terms of the system calls provided by the kernel². And yet, it would be a rare program that is designed in this way when the higher level interface of glibc requires fewer lines of source code to achieve the same ends.