rane        05/09/19 14:52:04

  Added:       xml/htdocs/doc/en/articles linux-kernel-compiling.xml
  Log:
  new article from #104226

Revision  Changes    Path
1.1                  xml/htdocs/doc/en/articles/linux-kernel-compiling.xml

file : 
http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/articles/linux-kernel-compiling.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain: 
http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/articles/linux-kernel-compiling.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo

Index: linux-kernel-compiling.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header: 
/var/cvsroot/gentoo/xml/htdocs/doc/en/articles/linux-kernel-compiling.xml,v 1.1 
2005/09/19 14:52:04 rane Exp $ -->

<guide link="/doc/en/articles/linux-kernel-compiling.xml">
<title>Compiling the Linux kernel</title>

<author title="Author">
  <mail link="[EMAIL PROTECTED]">Daniel Robbins</mail>
</author>
<!-- xmlified by: Joshua Saddler ([EMAIL PROTECTED]) -->

<abstract>
Daniel Robbins introduces the Linux kernel, and then walks you through locating
and downloading sources, configuring the kernel, compiling and installing the
kernel, and boot configuration.
</abstract>

<!-- The original version of this article was first published on IBM 
developerWorks, and is property of Westtech Information Services. This 
document is an updated version of the original article, and contains
various improvements made by the Gentoo Linux Documentation team -->

<version>1.0</version>
<date>2005-08-31</date>

<chapter>
<title>Introducing the kernel</title>
<section>
<title>The kernel is... Linux!</title>
<body>

<note>
The original version of this article was first published on IBM developerWorks,
and is property of Westtech Information Services. This document is an updated
version of the original article, and contains various improvements made by the
Gentoo Linux Documentation team.
</note>

<p>
What do you think of when you hear the word "Linux"? When I hear it, I
typically think of an entire Linux distribution and all the cooperating
programs that make the distribution work.
</p>

<p>
However, you may be surprised to find out that, technically, Linux is a kernel,
and a kernel only. While the other parts of what we commonly call "Linux" (such
as a shell and compiler) are essential parts of a distribution, they are
technically separate from Linux (the kernel). While many people use the word
"Linux" to mean "Linux-based distribution," everyone can at least agree that
the Linux kernel is the <e>heart</e> of every distribution.
</p>

</body>
</section>
<section>
<title>Interfacing with hardware</title>
<body>

<p>
The primary role of the Linux kernel is to interface directly with the hardware
in your system. The kernel provides a <e>layer of abstraction</e> between the
raw hardware and application programs.  This way, the programs themselves do
not need to know the details of your specific motherboard chipset or disk
controller -- they can instead operate at the higher level of reading and
writing files to disk, for example.
</p>

</body>
</section>
<section>
<title>CPU abstraction</title>
<body>

<p>
The Linux kernel also provides a level of abstraction on top of the
processor(s) in your system -- allowing for multiple programs to appear to run
simultaneously. Linux does this by allowing several UNIX <e>processes</e> to
run at once -- and the kernel takes care of giving each one a fair share of the
processor(s).
</p>

<p>
A Linux kernel can support either a single or multiple CPUs -- and the kernel
that you are using now is either uniprocessor-aware (UP-aware) or symmetric
multiprocessor-aware (SMP-aware). If you happen to have an SMP motherboard, but
you're using a UP kernel, Linux won't "see" your extra processors! To fix this,
you'll want to compile a special SMP kernel for your hardware. Currently, SMP
kernels will also work on uniprocessor systems, but at a slight performance
hit.
</p>

</body>
</section>
<section>
<title>Abstracting I/O</title>
<body>

<p>
The kernel also handles the much-needed task of abstracting all forms of file
I/O. Imagine what would happen if every program had to interface with your
particular hardware directly -- if you changed disk controllers, all your
programs would stop working!  Fortunately, the Linux kernel follows the UNIX
model of providing a simple abstraction of disk I/O that all programs can use.
That way, your favorite database doesn't need to be concerned whether it is
storing data on an IDE disk, a SCSI RAID array, or a network-mounted file
system.
</p>

</body>
</section>
<section>
<title>Networking Central</title>
<body>

<p>
One of Linux's main claims to fame is its robust networking, especially TCP/IP
support. And, if you guessed that the TCP/IP stack is in the Linux kernel,
you're right! The kernel provides a nice, high-level interface for programs
that want to send data over the network. Behind the scenes, the Linux kernel
interfaces directly with your particular ethernet card or modem, and handles
the low-level Internet communication details.
</p>

</body>
</section>
<section>
<title>Networking goodies</title>
<body>

<p>
One of the greatest things about Linux is all of the useful features that are
available in the kernel, especially those related to networking. For example,
you can configure a kernel that will allow your entire home network to access
the Internet via your Linux modem -- this is called IP Masquerading, or IP NAT
(network address translating).
</p>

<p>
Additionally, the Linux kernel can be configured to export or mount
network-based NFS file systems, allowing for other UNIX machines on your LAN to
easily share data with your Linux system.
</p>

</body>
</section>
<section>
<title>Booting, part 1</title>
<body>

<p>
When you turn on your Linux-based system, the kernel is loaded from disk to
memory by a boot loader, such as LILO. At this point, the kernel takes control
of your system. The first thing it does is detect and initialize all the
hardware that it finds -- and it has been compiled to support. Once the
hardware has been initialized properly, it is then ready to run processes. The
first process it runs is called <c>init</c>, which is located in
<path>/sbin</path>. Then, <c>init</c> starts additional processes, as
specified in <path>/etc/inittab</path>.
</p>

</body>
</section>
<section>
<title>Booting, part 2</title>
<body>

<p>
<c>init</c> typically starts several copies of a program called <c>getty</c>,
which waits for logins from the console. After <c>getty</c> successfully
processes a login request, your default shell is loaded (which is typically
<c>bash</c>). Once you're in bash, you have the power to launch any program
you'd like.
</p>

<p>
While all these new processes are started, the kernel is still in control,
carefully time-slicing the CPU so that each process has a fair share. In
addition, the kernel continues to provide hardware abstraction and networking
services for the various running processes.
</p>

</body>
</section>
<section>
<title>Introducing... modules!</title>
<body>

<p>
All recent Linux kernels support kernel modules. Kernel modules are really neat
things -- they're pieces of the kernel that reside on disk, until needed. As
soon as the kernel needs the functionality of a particular module, it's loaded
from disk, automatically integrated with the kernel, and available for use.  In
addition, if a kernel module hasn't been used for several minutes, the kernel
can voluntarily unload it from memory -- something that's called
"autocleaning."
</p>




-- 
[email protected] mailing list

Reply via email to