[Up: tech] [Robot Wisdom home page]

Linux theory

Jorn Barger October 2002

computer = chips, disks, wires
input = typing, pointing, clicking (talking)
output = pixels, sounds

cpu inputs = programs, data = bits
cpu outputs = data (programs) = bits

programs = opcodes, addresses, offsets, masks, data

The cpu can't do anything but run programs, one at a time.

This used to (pre-1970) involve feeding in one program (eg on a deck of punched cards) and clicking 'run'.

Unix was designed to remember many programs on disk(s), and let various separate simultaneous users (eg at terminals) share the cpu without stepping on each others' toes.

The operating system's main job is to efficiently juggle which programs run when, moving them from disk to RAM and back.

(On home pcs without 'true multitasking' you'll often have to wait for a slow program to finish before the keyboard will even respond.)

Since several users at once may want to run the same program, Unix treats each of these as a separate 'process'.

Each user has well-defined privileges that usually include a private storage area.

To exercise those privileges the user has to log in.

Logging in usually means typing a name and password that are processed by a login program.

Even when no users are logged in, the login program must keep alert for input.

If the user's password matches, a new program is started up called a 'shell' that usually offers the user a command line for running other programs.

(If the user's display is based on windowing, each window will require a window-process along with the program's processes.)

The shell has to effectively lock out the user's ability to go beyond their defined privileges (eg accessing others' private storage, or hogging all the cpu-time).

But if the user is allowed to run (or write) new programs, there's a theoretical risk that these programs might 'pick the locks'.

So the locks have to be built directly into the hardware-- the 80386's 'protected' memory modes made this possible for Linux.

The same locks can prevent a buggy program from accidentally disrupting others' work, which is why a program-crash in Linux won't normally require re-booting the machine.

The locks are implemented in the 80386 by breaking up RAM into 4k 'page-frames' that can be individually defined as locked or unlocked for each user-process.

Only the 'root' user's processes can set those locks.

os typology


You can submit a new URL or any other suggestion for this page by typing it into the box below. It will instantly become visible to anyone at this comments page. I should get around to checking it out and updating it above within a week or three, at which point I'll delete it from the comments page.

If you want credit, include your name and email (otherwise it's anonymous). You can use HTML but you don't have to.

[Up: tech] [Site map] [Robot Wisdom home page]

Related pages:
Linux/Unix: timeline theory kernel distros installing
Timelines: Microsoft 80386
Early Unix-like OSes for micros timeline
Internet Timelines Project: XML-theory
Regular expressions resources
DecentOS design ideas
FirstCut parser design ideas

(Feedback to jorn@robotwisdom.com)

Search this site Search full Web

Before you leave this site: Be sure you've checked out Jorn's weblog which offers daily updates on the best of the Web-- news etc, plus new pages on this site. See also the overview of the hundreds of pages of original content offered here, and the offer for a printed version of the site.

Hosting provided by instinct.org. Content may be copied under Open Web Content License.