240 lines
6.2 KiB
HTML
240 lines
6.2 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>What happens when you run programs
|
|
after boot time?</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="The Unix and Internet Fundamentals HOWTO"
|
|
HREF="index.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="What happens when you log in?"
|
|
HREF="login.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="How do input devices and interrupts work?"
|
|
HREF="devices.html"></HEAD
|
|
><BODY
|
|
CLASS="sect1"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>The Unix and Internet Fundamentals HOWTO</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="login.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="devices.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="sect1"
|
|
><H1
|
|
CLASS="sect1"
|
|
><A
|
|
NAME="running-programs"
|
|
></A
|
|
>5. What happens when you run programs
|
|
after boot time?</H1
|
|
><P
|
|
>After boot time and before you run a program, you can think of your
|
|
computer as containing a zoo of processes that are all waiting for
|
|
something to do. They're all waiting on <I
|
|
CLASS="firstterm"
|
|
>events</I
|
|
>. An
|
|
event can be you pressing a key or moving a mouse. Or, if your machine is
|
|
hooked to a network, an event can be a data packet coming in over that
|
|
network.</P
|
|
><P
|
|
>The kernel is one of these processes. It's a special one, because it
|
|
controls when the other <I
|
|
CLASS="firstterm"
|
|
>user processes</I
|
|
> can run, and it
|
|
is normally the only process with direct access to the machine's hardware.
|
|
In fact, user processes have to make requests to the kernel when they want
|
|
to get keyboard input, write to your screen, read from or write to disk, or
|
|
do just about anything other than crunching bits in memory. These requests
|
|
are known as <I
|
|
CLASS="firstterm"
|
|
>system calls</I
|
|
>.</P
|
|
><P
|
|
>Normally all I/O goes through the kernel so it can schedule the
|
|
operations and prevent processes from stepping on each other. A few
|
|
special user processes are allowed to slide around the kernel, usually by
|
|
being given direct access to I/O ports. X servers are the most common
|
|
example of this.</P
|
|
><P
|
|
>You will run programs in one of two ways: through your X server
|
|
or through a shell. Often, you'll actually do both, because you'll
|
|
start a terminal emulator that mimics an old-fashioned textual console,
|
|
giving you a shell to run programs from. I'll describe what happens
|
|
when you do that, then I'll return to what happens when you run a program
|
|
through an X menu or desktop icon.</P
|
|
><P
|
|
>The shell is called the shell because it wraps around and hides the
|
|
operating system kernel. It's an important feature of Unix that the shell
|
|
and kernel are separate programs communicating through a small set of
|
|
system calls. This makes it possible for there to be multiple shells,
|
|
suiting different tastes in interfaces.</P
|
|
><P
|
|
>The normal shell gives you the ‘$’ prompt that you see
|
|
after logging in (unless you've customized it to be something else). We
|
|
won't talk about shell syntax and the easy things you can see on the screen
|
|
here; instead we'll take a look behind the scenes at what's happening from
|
|
the computer's point of view.</P
|
|
><P
|
|
>The shell is just a user process, and not a particularly special one.
|
|
It waits on your keystrokes, listening (through the kernel) to the keyboard
|
|
I/O port. As the kernel sees them, it echoes them to your virtual console or
|
|
X terminal emulator. When the kernel sees an ‘Enter’ it passes
|
|
your line of text to the shell. The shell tries to interpret those
|
|
keystrokes as commands.</P
|
|
><P
|
|
>Let's say you type ‘ls’ and Enter to invoke the Unix
|
|
directory lister. The shell applies its built-in rules to figure out that
|
|
you want to run the executable command in the file
|
|
<TT
|
|
CLASS="filename"
|
|
>/bin/ls</TT
|
|
>. It makes a system call asking the kernel to
|
|
start /bin/ls as a new <I
|
|
CLASS="firstterm"
|
|
>child process</I
|
|
> and give it
|
|
access to the screen and keyboard through the kernel. Then the shell goes
|
|
to sleep, waiting for ls to finish.</P
|
|
><P
|
|
>When <B
|
|
CLASS="command"
|
|
>/bin/ls</B
|
|
> is done, it tells the kernel it's
|
|
finished by issuing an <I
|
|
CLASS="firstterm"
|
|
>exit</I
|
|
> system call. The kernel
|
|
then wakes up the shell and tells it it can continue running. The shell
|
|
issues another prompt and waits for another line of input.</P
|
|
><P
|
|
>Other things may be going on while your ‘ls’ is
|
|
executing, however (we'll have to suppose that you're listing a very long
|
|
directory). You might switch to another virtual console, log in there, and
|
|
start a game of Quake, for example. Or, suppose you're hooked up to the
|
|
Internet. Your machine might be sending or receiving mail while
|
|
<B
|
|
CLASS="command"
|
|
>/bin/ls</B
|
|
> runs.</P
|
|
><P
|
|
>When you're running programs through the X server rather than a shell
|
|
(that is, by choosing an application from a pull-down menu, or
|
|
double-clicking a desktop icon), any of several programs associated with
|
|
your X server can behave like a shell and launch the program. I'm going to
|
|
gloss over the details here because they're both variable and unimportant.
|
|
The key point is that the X server, unlike a normal shell, doesn't go to
|
|
sleep while the client program is running — instead, it sits between
|
|
you and the client, passing your mouse clicks and keypresses to it and
|
|
fulfilling its requests to point pixels on your display.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="login.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="devices.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>What happens when you log in?</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
> </TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>How do input devices and interrupts work?</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |