alex,
I was hoping someone more qualified would respond, but I'll give it a
try. This writing is pretty rough -- some day I would hope to clean it
up and put it on my wiki (after the wiki is running).
alex wrote:
> What is meant by: ?
>
> 'unpack' as in-- unpack to /usr/src
Packing is sort of like compression, or something that is usually done
along with compression. Utilities like zip in the dos/Windows world
(and Linux) combine multiple files into one file and compress each of
them. (I think they are individually compressed and then combined, but
it might be the other way around -- clearly we can extract and
uncompress individual files which is what makes my first impression that
they are compressed and then combined, but it could work either way --
the combining is what is usually called packing.)
In the Linux world, there are utilities that just do packing (tar, I
think) and other utilities that just do compressing (not sure --
gzip?). (And, nowadays, just to confuse me, tar has the ability to
compress as well.)
Anyway, packing is the act of combining multiple files into one (for
convenience under some circumstances), unpacking is the act of
separating that single file back into the original separate files. And,
in today's world, somebody talking about packing or unpacking may be
implying compression or uncompression as well.
> 'link' as in-- link linux to kernel-source (what's a
> kernel-source?)
2nd question first: Most programs exist in two forms -- a human
readable form that the programmer creates, reads, and modifies, and a
machine readable form that the computer actually runs. The human
readable form is commonly referred to as the source. This gets touched
on below, in several places.
Link: link can have more than one meaning in the computer world. In
this context (AFAICT) you want to know about the act of linking several
parts of a computer program together to make one. (I'm not a C or C++
programmer, and linking is an operation more common to those languages
than to, for example, Pascal, so I'm a little uncomfortable here, but
I'll try:)
We'll go back to the two forms of a program (and we'll touch on some of
your other questions as well):
The human readable form of a program is usually compiled (but sometimes
interpreted -- slightly different) to convert it from source (code) to
the machine readable form (variously called object (code), binary, or
executable depending on other circumstances).
The human readable source code is often maintained in separate pieces
for convenience, each piece in a separate file. (It's often easier to
deal with several smaller files rather than one large file, depending on
what you're trying to do at the moment.) A compiler (one of two types
of computer program that converts the human readable form to the machine
readable form) typically converts each separate source file to a
separate machine readable file (usually known as an object file).
Before the computer can run the program, the separate pieces have to be
combined into one program, by a process called "linking". (There is a
lot more to learn about linking, like exactly what does linking do --
what within each separate piece is linked? For another discussion.)
Aside: The other meaning of linking has to do with having one file or
directory pretend to be another, via a hard or soft link -- if you want
to know more about that, write back. (Well, actually, I covered some of
that below in your question about inodes.)
> 'compile' as in-- compile the kernel (or recompile)
I hope I gave you the general idea of compiling already -- it is one way
of transforming the human readable form of a computer program to the
computer readable form (or maybe I should say the computer executable
form -- the computer can "read" the human readable program, but can't
directly execute it (unless it is an interpreted language, mentioned
again below)).
Recompiling is simply compiling a program again, because you've modified
it, fixed an error, want to make it run on a different (type of)
computer, or something similar.
Someone more used to compiling might explain the typical steps for
compiling with a compiler like gcc -- the various make, make clean, and
build commands. (I don't know enough to attempt that, yet.) (It's
easier in Turbo Pascal or Visual Basic, you just compile.)
Aside: Some languages are interpreted instead of compiled (and a few can
be compiled or interpreted). The basic difference is that compiling is
done in advance, before a program is run, interpreting is done on the
fly. To expand -- a compiled program is programmed, compiled, linked,
and then run, all separate steps, and before a program is run, a
complete translated copy exists in a file (the product of the
compilation and linking steps). An interpreted program is just
programmed and then run -- the interpreter reads one line of the source
code at a time, translates it to source code, executes it, then gets the
next line of the program, translates it, and so on.
Compiling usually produces programs that run faster. Interpreting
usually helps a programmer write and debug a program more quickly. For
languages that can be compiled or interpreted, it is common to interpret
the program until the programmmer has "perfected it", then it is
compiled so it will run faster.
> 'building' as in-- building a dependency tree
Ok, now I'm further out of my element, but I think I can handle this.
Back to the program being maintained in separate files for convenience.
If a program is maintained in separate files, it is possible that
something within the overall program is needed in one file but is
defined (created) in another file. In that case, we can say that the
file that needs the something depends on the file where it is created.
In a typical program, there are many files, and many files depend on
other files, and usually, many of those files depend on some other
files. (There can even be files which depend on each other which, I
think, is usually a mistake.) At least at the linking step, the files
that depend on other files must not be linked until the files they
depend on are linked. (I don't think it is required at the compiling
step, but I'm not sure). Determining which files depend on which others
and determining which files must be linked first is what building a
dependency tree is all about. The dependency tree determines in which
order the files must be linked so there are no "unresolved dependencies"
as the program is linked together.
There are programs that do this, I think the program known as "make" is
the predominant one. (Actually there are several called make, I think.
There are also programs called automake and autoconf that you may
eventually need to become familiar with -- I don't really know what they
do, exactly (clearly, my guess is at least automake has something to do
with this same process.)
> " " " building a kernel
I think "building" here is used in a slightly different more global
context, and is referring to the entire process of compiling, linking,
etc. to "build" the machine readable kernel program from the human
readable source code for the kernel.
> 'inodes' --- ?
In Linux (maybe some other operating systems, but not in AFAIK in
dos/Windows), an inode is a number that refers to a specific storage
location in a file system (like on a hard disk). Linux directories are
set up something like this:
There is a place where a filename appears on the disk (like myfile.txt),
and in that place, there is an inode number (and some other information)
that indicates where on the disk the contents of myfile.txt is stored.
The equivalent of the place where the filename and inode are stored in
dos would be known as the fat (file allocation table) -- I'm not sure if
it's the same in Linux. (And, actually, there is usually more than one
inode stored here -- many (most?) files require more than one inode to
store an entire file, so the inodes for the first several locations are
stored in the fat. (But not necessarily all inodes.) Really, I'm
beyond my depth here and if you want to know more you should get a good
reference on this material. Try searching for some combination of
inode, Linux, filesystem, and link on Google.)
There is a point of potential confusion here, and it takes us to the
other meaning of link.
In Linux, there can be hard links and soft links between files. A hard
link is created by having two or more file names, all of which point to
the same "string" (series) of inodes. It's one way of having two
different names for a file. (Again, the content of the file is stored
in the locations on disk defined by the inodes -- if two file names each
refer to the same series of inodes, they both have the same content (and
a change to the content of one file will change the content of the other
file, because there is only one copy of the content.) (A soft link is
similar but slightly different -- again I'm going to put you off here --
if you need to know more, write back or look for a good reference. Note
that there are reasons for two different kinds of links -- each has
advantages and disadvantages which I have not mentioned here.)
> 'threads' --- ?
OK.... Wow, deeper and deeper. I'm going to go take care of a chore
and then tackle this one.
Ok... clearly this is a computer topic, but we need to come from a
different slant to talk about this.
Many people think that a computer can do several things at the same
time. For purposes of this dicussion, assume that that is not true
(most computer programmers would agree in general with that, but someone
might argue on the basis of multiple CPUs, or DMA, the fact that a video
or sound card can be displaying video or playing sound while the CPU is
doing something else. In fact, my first explanation is going to deal
with threads in what some people might consider the old definition,
before there were multiple CPUs in a single computer.
Anyway, in a single CPU computer, the CPU can do only one thing at a
time. It can do that one thing very quickly. If you have a 100 MHz.
processor, it can do 100,000,000 things in one second, but each one
takes 1/100,000,000 seconds to do (10 nanoseconds) to do, and each one
is done one at a time, one after the other.
Multiprocessing is a way of making you think the computer is doing more
than one thing at a time.
Aside: The one thing that a computer does at one time is usually not
something that we as humans would consider very useful. The computer
may have to do 100 (or more, or less) of those things to make the letter
"a" appear on our video screen. But, if it can put the letter "a" on
our video screen in 100 steps, in one second it can put one million "a"s
on our screen (which wouldn't fit, and would take us a long time to
count, but that's beside the point. Now if the computer puts an "a" on
our screen (with 100 instructions), and then outputs a note to our sound
card (with a different set of 100 instructions), and then checks the
keyboard for any input (with a different set of instructions), and then
reads or writes something to memory, or the hard disk, and then puts
another "a" on the screen, we (usually) won't even notice that the
computer is doing anything else.
So, that's:
1. How a computer appears to do more than one thing at the same time --
to go a little bit further, typically, each program takes turns at using
the computer. When a computer is set up this way, it is known as
multitasking, and the operating system is in charge of making the
programs take turns. (For a different day, we could discuss pre-emptive
vs. cooperative (??) multitasking.) Each turn consists of a slice of
time (anywhere from a tenth to a millionth of a second).
2. The basis for an explanation of threads -- in fact, each of the tasks
we listed may be part of a different thread.
Other words for thread (which don't necessarily convey exactly the same
or the entire meaning of thread) include program and process.
Start by thinking of a thread as computer program dedicated to
performing one type of task, displaying characters on your screen,
playing sound on your sound card, reading or writing to/from memory or
the hard disk, checking the keyboard, or whatever.
Now recognize that most useful computer programs don't do just one of
those things, but do a combination of things, they may read a program
and data in from a disk, store it in memory, wait for you to enter a
command at the keyboard, then display something on the screen, and so
forth. Some times these things must be done in a certain sequence, (or
at least are done in a certain sequence) -- the program is read from
disk before the program starts checking the keyboard for commands, but,
really even this is not strictly necessary -- a small part of the
program could be read in from disk, a part that just checks the keyboard
for input, while other parts of the program are read in later -- they
may even wait until some keyboard input requires that some part of the
program be read in.
So now, if you've followed this far, I think you can see the potential
for what you or I think of as one program to actually be several smaller
programs. One small program is the initial loader and keyboard reader.
It is read into memory and started. It watches for keyboard input. If
it sees a command like "save xxx", it might tell another program to load
itself to do the save command, or if it sees a need to display a picture
on the display, it might call another program to read the picture off
the disk (or out of memory) and display it on the display.
Each of these separate programs is (can be considered) a thread.
They could also be one monolithic program, not threaded.
One difference would be this.
In the monolithic program, while the picture was being read off disk to
be displayed, that would be the only activity that this program would be
doing. (Point of potential confusion -- on a multitasking system, other
programs might be doing other things "at the same time" (i.e., in their
respective time slice), but this particular program would not do any
other task until the picture was loaded and then displayed. Then this
program would be ready to go on to some other task, like watching the
keyboard again for new commands. (This is a little oversimplified --
people have written programs without threads that behave a little
differently.)
If you break the program into threads, each thread can be treated as a
separate program, and get its own time slice. So just like it can
appear that a computer is running many programs at once, now, with
multithreading, it can appear that a single program is doing many things
at once -- one time slice it is reading data from disk getting ready to
display the picture, another time slice is watching the keyboard, and,
if a new command is issued, to print the picture, a new thread can start
with it's own set of time slices, starting to send the picture to the
printer.
This has been a simplified introduction into the idea of threads. If I
think about, or if you have questions, I can perhaps clarify some
things. I will end with a few observations without much explanation:
-Now that there are computers with multiple CPUs, threads of one program
do not necessarily have to always share the same processor -- they might
use one of the other processors. This can be an advantage or not
depending on circumstances. (One drawback is that more data may have to
be made available to that other processor, and "somebody" must move the
data between the processors -- in other words, it takes time, processor
cycles, or both.)
-Also, now that there are computers with multiple CPUS, it seems that a
"new definition" of threading exists that seems to only consider
threading on multiple processor computers to be "real threading".
-Threading clearly requires some overhead (passing data back and forth
on a multi-CPU machine, starting and stopping (switching) tasks on a
single (or multiple) CPU machine. I haven't discussed that very much.
There are ways of doing "threading" that require more or less overhead.
Threading seems to often be considered the method that uses the most
overhead (but in some sense is "safest"). There are ways of doing it
with less overhead (I just can't think of the term(s) for those other
ways -- sometimes they are referred to generally as "lightweight methods
of threading". There are real tradeoffs to be considered between the
methods.
Well, I'm "written out" for now -- I'm going to send this, without
thorough proofreading -- let me know what is confusing and we can go
further (maybe).
Hope this helps,
Randy Kramer
