lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add directory docs

Browse Source
This commit is contained in:
gohigh
2024-02-19 00:23:35 -05:00
parent b50063d9b3
commit 9912ec445d
12689 changed files with 3135349 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

443
docs/kernelhacking-HOWTO/index.html Normal file
View File

@@ -0,0 +1,443 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<title>Kernel Hacking HOWTO</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.40">
<link rel="home" href="index.html" title="Kernel Hacking HOWTO">
<link rel="next" href="indexs02.html" title="Structure">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Kernel Hacking HOWTO</th></tr>
<tr>
<td width="20%" align="left"><EFBFBD></td>
<th width="60%" align="center"><EFBFBD></th>
<td width="20%" align="right"><EFBFBD><a href="indexs02.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="article">
<div class="titlepage">
<div><h2 class="title">
<a name="id46569096"></a>Kernel Hacking HOWTO</h2></div>
<div>
<h3 class="author">Andrew Ebling</h3>
<div class="affiliation"><div class="address"><tt>&lt;<a href="mailto:kh.howto@andyebling.clara.co.uk">kh.howto@andyebling.clara.co.uk</a>&gt;</tt></div></div>
</div>
<div><div class="revhistory"><table border="1" width="100%" summary="Revision history">
<tr><th align="left" valign="top" colspan="3"><b>Revision History</b></th></tr>
<tr>
<td align="left">Revision 0.16</td>
<td align="left">2002-1-17</td>
<td align="left">ajme</td>
</tr>
<tr><td align="left" colspan="3">Complete read thru following a good break, spell &amp; grammar review, added abstract, revised Introduction and prerequisites, new email address, added some FAQs, added &quot;Your Turn&quot; sections.</td></tr>
<tr>
<td align="left">Revision 0.15</td>
<td align="left">2001-12-25</td>
<td align="left">ajme</td>
</tr>
<tr><td align="left" colspan="3">Conversion to DocBook 3.1 SGML to make maintaining the glossary less time consuming, full spell check and a lot of small fixes and improvements.</td></tr>
<tr>
<td align="left">Revision 0.14</td>
<td align="left">2001-12-16</td>
<td align="left">ajme</td>
</tr>
<tr><td align="left" colspan="3">Started glossary, lots of small fixes.</td></tr>
<tr>
<td align="left">Revision 0.13</td>
<td align="left">2001-12-05</td>
<td align="left">ajme</td>
</tr>
<tr><td align="left" colspan="3">Added &quot;Boot time Parameters&quot; section in &quot;General Hacking&quot;, CVS section added in tools chapter, &quot;The Linux Kernel Development Cycle&quot; section started, more URLs added and lots more small fixes.</td></tr>
<tr>
<td align="left">Revision 0.12</td>
<td align="left">2001-12-04</td>
<td align="left">ajme</td>
</tr>
<tr><td align="left" colspan="3">Emacs section added in tools chapter, lots more small fixes.</td></tr>
<tr>
<td align="left">Revision 0.11</td>
<td align="left">2001-12-01</td>
<td align="left">ajme</td>
</tr>
<tr><td align="left" colspan="3">Conversion to SGML, fixing it up to be like an LDP HOWTO plus numerous small fixes.</td></tr>
<tr>
<td align="left">Revision 0.10</td>
<td align="left">2001-11-25</td>
<td align="left">ajme</td>
</tr>
<tr><td align="left" colspan="3">Initial release.</td></tr>
</table></div></div>
<hr>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt> <a href="index.html#intro">Introduction</a>
</dt>
<dd><dl>
<dt> <a href="index.html#who">Who this document is for</a>
</dt>
<dt> <a href="index.html#whyhack">Why hack the kernel?</a>
</dt>
<dt> <a href="index.html#prerequisites">Prerequisites</a>
</dt>
<dt> <a href="index.html#copyright">Copyright</a>
</dt>
<dt> <a href="index.html#Disclaimer">Disclaimer</a>
</dt>
<dt> <a href="index.html#news">News</a>
</dt>
<dt> <a href="index.html#credits">Credits</a>
</dt>
<dt> <a href="index.html#translation">Translations</a>
</dt>
<dt> <a href="index.html#contact">Contacting the Author</a>
</dt>
</dl></dd>
<dt> <a href="indexs02.html">Structure</a>
</dt>
<dt> <a href="indexs03.html">Linux Kernel Overview</a>
</dt>
<dd><dl>
<dt> <a href="indexs03.html#kernel-introduction">Introduction</a>
</dt>
<dt> <a href="indexs03.html#kernel-kernelmodes">Kernel Modes</a>
</dt>
<dt> <a href="indexs03.html#kernel-modules">Modules</a>
</dt>
<dt> <a href="indexs03.html#kernel-process">Processes</a>
</dt>
<dt> <a href="indexs03.html#kernel-sync">Synchronisation</a>
</dt>
<dt> <a href="indexs03.html#kernel-ipc">Signals and Inter Process Communication</a>
</dt>
<dt> <a href="indexs03.html#kernel-mm">Memory Management</a>
</dt>
<dt> <a href="indexs03.html#kernel-vfs">Virtual File system</a>
</dt>
<dt> <a href="indexs03.html#kernel-diskcache">Disk Caches</a>
</dt>
<dt> <a href="indexs03.html#overviewyourturn">Your Turn</a>
</dt>
</dl></dd>
<dt> <a href="indexs04.html">Source Tour</a>
</dt>
<dd><dl>
<dt> <a href="indexs04.html#whatgoeswhere">What goes where</a>
</dt>
<dt> <a href="indexs04.html#keydatastructures">Key data structures</a>
</dt>
<dt> <a href="indexs04.html#startingpoints">Starting Points</a>
</dt>
<dt> <a href="indexs04.html#srctouryourturn">Your Turn</a>
</dt>
</dl></dd>
<dt> <a href="indexs05.html">Tools</a>
</dt>
<dd><dl>
<dt> <a href="indexs05.html#editors">Editors</a>
</dt>
<dt> <a href="indexs05.html#vim">vim</a>
</dt>
<dt> <a href="indexs05.html#emacs">emacs</a>
</dt>
<dt> <a href="indexs05.html#development">Development</a>
</dt>
<dt> <a href="indexs05.html#srccodenav">Source Code Navigation</a>
</dt>
<dt> <a href="indexs05.html#sourcecodemanipulation">Source Code Manipulation</a>
</dt>
<dt> <a href="indexs05.html#toolsyourturn">Your Turn</a>
</dt>
</dl></dd>
<dt> <a href="indexs06.html">Tasks</a>
</dt>
<dd><dl>
<dt> <a href="indexs06.html#generalkernel">General Kernel</a>
</dt>
<dt> <a href="indexs06.html#generalhacking">General Hacking</a>
</dt>
<dt> <a href="indexs06.html#bughunting">Bug Hunting</a>
</dt>
</dl></dd>
<dt> <a href="indexs07.html">Basic Functions</a>
</dt>
<dt> <a href="indexs08.html">Drivers &amp; Modules</a>
</dt>
<dt> <a href="indexs09.html">Kernel Debugging</a>
</dt>
<dd><dl>
<dt> <a href="indexs09.html#whenthingsgowrong">When things go wrong</a>
</dt>
<dt> <a href="indexs09.html#oopsanalysis">Oops Analysis</a>
</dt>
<dt> <a href="indexs09.html#usingadebugger">Using a Debugger</a>
</dt>
<dt> <a href="indexs09.html#debugsession">The Debugging Session</a>
</dt>
<dt> <a href="indexs09.html#troubleshooting">Troubleshooting</a>
</dt>
<dt> <a href="indexs09.html#miscnotes">Misc. Notes</a>
</dt>
<dt> <a href="indexs09.html#usingthelogs">Using the logs</a>
</dt>
</dl></dd>
<dt> <a href="indexs10.html">Profiling &amp; Benchmarking</a>
</dt>
<dd><dl>
<dt> <a href="indexs10.html#whyprofile">Why profile?</a>
</dt>
<dt> <a href="indexs10.html#basicprofiling">Basic profiling</a>
</dt>
</dl></dd>
<dt> <a href="indexs11.html">The Linux Kernel Development Cycle</a>
</dt>
<dd><dl>
<dt> <a href="indexs11.html#stableseries">Stable Series</a>
</dt>
<dt> <a href="indexs11.html#unstableseries">Unstable Series</a>
</dt>
<dt> <a href="indexs11.html#featurefreezes">Feature Freezes</a>
</dt>
<dt> <a href="indexs11.html#codefreezes">Code Freezes</a>
</dt>
<dt> <a href="indexs11.html#intermediatepatches">Intermediate Patches</a>
</dt>
<dt> <a href="indexs11.html#devyourturn">Your Turn</a>
</dt>
</dl></dd>
<dt> <a href="indexs12.html">Tips</a>
</dt>
<dd><dl>
<dt> <a href="indexs12.html#codingtips">Coding Tips</a>
</dt>
<dt> <a href="indexs12.html#gendevtips">General Development Tips</a>
</dt>
</dl></dd>
<dt> <a href="indexs13.html">More Information</a>
</dt>
<dd><dl>
<dt> <a href="indexs13.html#srccodedocs">Source code docs</a>
</dt>
<dt> <a href="indexs13.html#links">Links</a>
</dt>
<dt> <a href="indexs13.html#books">Books</a>
</dt>
<dt> <a href="indexs13.html#web">Web</a>
</dt>
</dl></dd>
<dt> <a href="indexs14.html">Getting Help</a>
</dt>
<dd><dl>
<dt> <a href="indexs14.html#mailinglists">mailing lists</a>
</dt>
<dt> <a href="indexs14.html#irc">IRC</a>
</dt>
</dl></dd>
<dt> <a href="indexs15.html">FAQ</a>
</dt>
<dt> <a href="indexs16.html">To Do</a>
</dt>
<dt> <a href="indexs17.html">Glossary</a>
</dt>
<dt> <a href="indexs18.html">References &amp; Acknowledgments</a>
</dt>
</dl>
</div>
<div class="abstract">
<p>
<a name="id46569501"></a><b>Abstract</b>
</p>
<p>This document is a structured record of my own journey, from a relatively inexperienced application programmer to an even more inexperienced kernel programmer. By sharing my experience, I hope to make kernel hacking more accessible to other members of the open source community.
</p>
</div>
<div class="sect1">
<a name="intro"></a><div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="intro"></a>Introduction</h2></div></div>
<blockquote class="blockquote">
<font color="red">&lt;attributation&gt;Alan Cox on advice for new hackers, in an interview on http://www.kerneltrap.com with Jeremy Andrews&lt;/attributation&gt;</font><p>Ignore everyone who tells you kernel hacking is hard, special or different. It's a large program, and bug fixing or driver tweaking can be a best starting point. It is however not magic, nor written in a secret language that only deep initiates with beards can read.</p>
</blockquote>
<p>Kernel hacking may not be hard, but it certainly could not be described as easy. The lack of up to date, organised and comprehensive documentation hampers the efforts of even the most determined. Although there is actually quite a lot of information out there in books, web pages, newsgroups, mailing lists and the source itself, it is all very disparate, disorganised and on occasion contradictory.</p>
<p>This document aims to address this issue. Hopefully it will attract bright new talent to the Linux Kernel Community. One day, someone will have to take over from Linus!</p>
<div class="sect2">
<a name="who"></a><div class="titlepage"><div><h3 class="title">
<a name="who"></a>Who this document is for</h3></div></div>
<p>This document is aimed at:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46570209"></a>Those who are confident compiling the Linux kernel, would like to contribute to it's development, but feel intimidated by the 2 million lines of kernel source code.</p></li>
<li><p>
<a name="id46570184"></a>Those who want to find out if kernel programming is of interest.</p></li>
<li><p>
<a name="id46570189"></a>Those who would like to get involved in kernel development but don't have time to figure everything out for themselves.
<li><p>
<a name="id46570217"></a>Those who want to improve their kernel programming productivity.</p></li>
</p></li>
</ul></div>
<p>It aims to accelerate the learning process by:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46570227"></a>Bringing together into one place as much key information as possible.</p></li>
<li><p>
<a name="id46570233"></a>Providing &quot;the basics&quot; in key areas.</p></li>
<li><p>
<a name="id46570413"></a>Supplying pointers to more in-depth information.</p></li>
</ul></div>
</div>
<div class="sect2">
<a name="whyhack"></a><div class="titlepage"><div><h3 class="title">
<a name="whyhack"></a>Why hack the kernel?</h3></div></div>
<p>Some reasons why people get into kernel programming:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46570425"></a>They find the current kernel inadequate in some way and want to help fix the problem, perhaps by writing a new device driver or by working on improving the performance of one of the kernel's subsystems.</p></li>
<li><p>
<a name="id46570433"></a>They want to learn how a real operating system works, as opposed to the vague, high level concepts taught on most computer architecture courses.</p></li>
<li><p>
<a name="id46570438"></a>They like Linux and want to contribute to its development.</p></li>
<li><p>
<a name="id46570441"></a>They find application programming too easy or boring and are looking for something more challenging!</p></li>
</ul></div>
</div>
<div class="sect2">
<a name="prerequisites"></a><div class="titlepage"><div><h3 class="title">
<a name="prerequisites"></a>Prerequisites</h3></div></div>
<p>What should I know before I start working through this document?</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46570453"></a>A fair amount of Linux experience from a user/developer perspective. If you are happy to use the console rather than X-windows to do most of your development work, you are probably ready.</p></li>
<li><p>
<a name="id46570461"></a>The ability to compile you own kernel. If this does not include you then read, understand, follow and commit to memory the steps given in the <a href="http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html" target="_top">Kernel-HOWTO</a>.</p></li>
<li><p>
<a name="id46570468"></a>A good, working knowledge of the C programming language. If this does not include you, why not start learning now? There are many good books on C, some of which are well suited to home/self learning e.g. SAMS Publishing &quot;Teach Yourself in 21 Days/24 Hours&quot; series. Alternatively you can find good C tutorials online at <a href="http://directory.google.com/Top/Computers/Programming/Languages/C/Tutorials/" target="_top">google groups.</a>
</p></li>
<li><p>
<a name="id46570483"></a>Some background knowledge of computer hardware and operating systems is useful but not essential.</p></li>
</ul></div>
</div>
<div class="sect2">
<a name="copyright"></a><div class="titlepage"><div><h3 class="title">
<a name="copyright"></a>Copyright</h3></div></div>
<p>Copyright (c) 2001/2002 Andrew Ebling</p>
<p>Please freely copy and distribute (sell or give away) this document in any format. It's requested that corrections and/or comments be forwarded to the document maintainer. You may create a derivative work and distribute it provided that you:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46570504"></a>Send your derivative work (in the most suitable format such as SGML) to the LDP (Linux Documentation Project) or the like for posting on the Internet. If not the LDP, then let the LDP know where it is available.</p></li>
<li><p>
<a name="id46570511"></a>License the derivative work with this same license or use GPL. Include a copyright notice and at least a pointer to the license used.</p></li>
<li><p>
<a name="id46570516"></a> Give due credit to previous authors and major contributors.</p></li>
</ul></div>
<p>If you're considering making a derived work other than a translation, it's requested that you discuss your plans with the current maintainer.</p>
</div>
<div class="sect2">
<a name="Disclaimer"></a><div class="titlepage"><div><h3 class="title">
<a name="Disclaimer"></a>Disclaimer</h3></div></div>
<p>Use the information in this document at your own risk. I disavow any potential liability for the contents of this document. Use of the concepts, examples, and/or other content of this document is entirely at your own risk.</p>
<p>All copyrights are owned by their owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark.</p>
<p>Naming of particular products or brands should not be seen as endorsements.</p>
<p>You are strongly recommended to take a backup of your system before modifying the kernel and make backups at regular intervals. If you would miss it if you lost it, back it up!</p>
</div>
<div class="sect2">
<a name="news"></a><div class="titlepage"><div><h3 class="title">
<a name="news"></a>News</h3></div></div>
<p>The latest version of this document will be available at the web site in a number of formats:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46570557"></a><a href="http://www.kernelhacking.org/docs/kernelhacking-HOWTO.sgml" target="_top">SGML source</a>
</p></li>
<li><p>
<a name="id46570567"></a><a href="http://www.kernelhacking.org/docs/kernelhacking-HOWTO.html" target="_top">HTML to read online</a>
</p></li>
<li><p>
<a name="id46570582"></a><a href="http://www.kernelhacking.org/docs/kernelhacking-HOWTO.html.tar.gz" target="_top">tar'ed multi-page HTML</a>
</p></li>
<li><p>
<a name="id46570585"></a><a href="http://www.kernelhacking.org/docs/kernelhacking-HOWTO.txt" target="_top">gzipped text</a>
</p></li>
</ul></div>
<p>The SGML source gets updated most frequently (i.e. whenever I have five minutes to spend on the document), the other formats only get updated for major new releases or when I feel the changes warrant the hassle.</p>
</div>
<div class="sect2">
<a name="credits"></a><div class="titlepage"><div><h3 class="title">
<a name="credits"></a>Credits</h3></div></div>
<p>I have the pleasure of acknowledging contributions from the following people:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46570618"></a>Adam Keys for his emacs contribution.</p></li>
<li><p>
<a name="id46570628"></a>Bruce Blinn for his CVS contribution.</p></li>
<li><p>
<a name="id46570636"></a>Rik van Riel for technical corrections.</p></li>
<li><p>
<a name="id46570640"></a>Jason Copenhaver, Guillaume Morin, Tero Kuusela, Tom Bradley for typos and grammar corrections.</p></li>
<li><p>
<a name="id46570645"></a>Igor Gilitschenski, Bohdan Vlasyuk, Tero Kuusela, Florian Zimmermann for general feedback, encouragement and suggestions.</p></li>
</ul></div>
<p>If you contributed a typo or grammar correction and your name is not in this list, it probably means that the error had already been reported and fixed. If you reported a problem that has not been fixed in the current version of this document, please re-send your bug report adding REPEAT to the subject line. I do my best to attend to all the reports I get sent, but occasionally something slips through the net.</p>
</div>
<div class="sect2">
<a name="translation"></a><div class="titlepage"><div><h3 class="title">
<a name="translation"></a>Translations</h3></div></div>
<p>As yet there are no translations of this document. Translations are welcome, but please contact me first.</p>
<p>Translation volunteers to date:</p>
<div class="itemizedlist"><ul><li><p>
<a name="id46570672"></a>Paulo Andre has offered to translate the document into Portuguese.</p></li></ul></div>
</div>
<div class="sect2">
<a name="contact"></a><div class="titlepage"><div><h3 class="title">
<a name="contact"></a>Contacting the Author</h3></div></div>
<p>Any comments or suggestions can be mailed to me:
<a href="mailto:kh.howto@andyebling.clara.co.uk?subject=KH%20HOWTO" target="_top">kh.howto@clara.co.uk</a>
</p>
<p>Please note that I am likely to be changing ISPs soon, so be sure to check the latest version of this document to get a &quot;live&quot; email address.</p>
<p>Please use these subject line conventions (in addition to your own short and concise subject) to help me handle queries efficiently and filter SPAM:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46570704"></a><a href="mailto:kh.howto@andyebling.clara.co.uk?subject=KH%20HOWTO%20QUESTION" target="_top">HOWTO QUESTION</a> for any howto related questions or to suggest an FAQ entry.</p></li>
<li><p>
<a name="id46570710"></a><a href="mailto:kh.howto@andyebling.clara.co.uk?subject=KH%20HOWTO%20RFC" target="_top">KH HOWTO RFC</a> for any &quot;request for change&quot; type suggestions.</p></li>
<li><p>
<a name="id46570725"></a><a href="mailto:kh.howto@andyebling.clara.co.uk?subject=KH%20HOWTO%20BUG" target="_top">KH HOWTO BUG</a> for any factual error or bug reports.</p></li>
<li><p>
<a name="id46570737"></a><a href="mailto:kh.howto@andyebling.clara.co.uk?subject=KH%20HOWTO%20TYPO" target="_top">KH HOWTO TYPO</a> for typo corrections.</p></li>
<li><p>
<a name="id46570742"></a><a href="mailto:kh.howto@andyebling.clara.co.uk?subject=KH%20HOWTO%20CONTRIB" target="_top">KH HOWTO CONTRIB</a> to submit a new section. (patch against latest SGML preferred.)</p></li>
<li><p>
<a name="id46570758"></a><a href="mailto:kh.howto@andyebling.clara.co.uk?subject=KH%20HOWTO%20SUGGEST" target="_top">KH HOWTO SUGGEST</a> to make a suggestion. (please check TO DO section at end of document first.)</p></li>
<li><p>
<a name="id46570768"></a><a href="mailto:kh.howto@andyebling.clara.co.uk?subject=KH%20HOWTO%20GLOSSARY" target="_top">KH HOWTO SUGGEST</a> to make a submission for the glossary.</p></li>
<li><p>
<a name="id46570777"></a><a href="mailto:kh.howto@andyebling.clara.co.uk?subject=KH%20HOWTO%20FEEDBACK" target="_top">KH HOWTO FEEDBACK</a> for general feedback.</p></li>
<li><p>
<a name="id46570788"></a><a href="mailto:kh.howto@andyebling.clara.co.uk?subject=KH%20HOWTO" target="_top">KH HOWTO</a> for any other howto related correspondence.</p></li>
</ul></div>
<p>I ruthlessly filter on subject, so any emails not following these conventions <i>may</i> silently/automatically get deleted. Subject lines like &quot;Hi!&quot;, &quot;hello&quot;, &quot;your website&quot; etc. are usually spam so are likely to get deleted without getting read. Thank you for understanding and co-operation.</p>
</div>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left"><EFBFBD></td>
<td width="20%" align="center"><EFBFBD></td>
<td width="40%" align="right"><EFBFBD><a href="indexs02.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left"><EFBFBD></td>
<td width="20%" align="center"><EFBFBD></td>
<td width="40%" align="right"><EFBFBD>Structure</td>
</tr>
</table>
</div>
</body>
</html>

60
docs/kernelhacking-HOWTO/indexs02.html Normal file
View File

@@ -0,0 +1,60 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<title>Structure</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.40">
<link rel="home" href="index.html" title="Kernel Hacking HOWTO">
<link rel="up" href="index.html" title="Kernel Hacking HOWTO">
<link rel="previous" href="index.html" title="Kernel Hacking HOWTO">
<link rel="next" href="indexs03.html" title="Linux Kernel Overview">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Structure</th></tr>
<tr>
<td width="20%" align="left">
<a href="index.html">Prev</a><EFBFBD></td>
<th width="60%" align="center"><EFBFBD></th>
<td width="20%" align="right"><EFBFBD><a href="indexs03.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="sect1">
<a name="structure"></a><div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="structure"></a>Structure</h2></div></div>
<p>This section presents an outline of the document as a whole, explaining the purpose and aim of each individual subsection. Hopefully this will enable the reader to ascertain which parts of the document are of most interest.</p>
<p>Some chapters are by nature, more &quot;hands on&quot;. The less practical chapters have a concluding section entitled &quot;Your Turn&quot;, which suggests an activity to consolidate the information presented.</p>
<p>The chapter entitled &quot;Linux Kernel Overview&quot; is intended to set the scene for the rest of the document by giving a high level summary of the most basic kernel concepts. This first chapter is designed to be a &quot;taster&quot;; if reading it produces a desire to know more, kernel programming (and therefore the rest of this document) is probably for you. Conversely, it may completely fail to interest you, in which case you may be better off writing yet another text editor or some other equally awe inspiring, user space application. ;)</p>
<p>The chapter entitled &quot;Source Tour&quot; explains what goes where in the kernel source tree. It encourages the bravest readers to get started reading some kernel code by listing some good starting points. Less confident readers may prefer to skim this chapter and come back to it later as reference material.</p>
<p>The chapter entitled &quot;Tools&quot; describes the various tools at the kernel hackers disposal. The idea here is to present relevant, basic, usage along with a source of more in depth documentation.</p>
<p>The chapter entitled &quot;Tasks&quot; outlines some common kernel development activities. It is hoped that these examples will enable a new hacker to work both efficiently and effectively right from the start, without having to read 101 man pages!</p>
<p>The chapter entitled &quot;Basic Functions&quot; aims to present the most fundamental kernel functions that every kernel hacker should know about and use on a day to day basis.</p>
<p>The chapter entitled &quot;Drivers &amp; Modules&quot; is not yet written.</p>
<p>The chapter entitled &quot;Kernel Debugging&quot; describes in detail an example debugging strategy, including how and how not to use a debugger. The aim is to encourage intelligent use of a debugger as a thought stimulation tool, to get to the real root of problems as they come to light.</p>
<p>The chapter entitled &quot;Profiling and Benchmarking&quot; explains what profiling is, how to profile kernel code and will eventually explain how to compare the performance of two kernel versions.</p>
<p>The chapter entitled &quot;The Linux Kernel Development Cycle&quot; explains the evolutionary process by which the kernel is continually improved and extended. It is intended as an aid to making appropriate contributions.</p>
<p>The remaining Tips, More Information, Getting Help, FAQ, To Do, Glossary and References &amp; Acknowledgments are hopefully self explanatory!</p>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a href="index.html">Prev</a><EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Home</a></td>
<td width="40%" align="right"><EFBFBD><a href="indexs03.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left">Kernel Hacking HOWTO<54></td>
<td width="20%" align="center"><a href="index.html">Up</a></td>
<td width="40%" align="right"><EFBFBD>Linux Kernel Overview</td>
</tr>
</table>
</div>
</body>
</html>

220
docs/kernelhacking-HOWTO/indexs03.html Normal file
View File

@@ -0,0 +1,220 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<title>Linux Kernel Overview</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.40">
<link rel="home" href="index.html" title="Kernel Hacking HOWTO">
<link rel="up" href="index.html" title="Kernel Hacking HOWTO">
<link rel="previous" href="indexs02.html" title="Structure">
<link rel="next" href="indexs04.html" title="Source Tour">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Linux Kernel Overview</th></tr>
<tr>
<td width="20%" align="left">
<a href="indexs02.html">Prev</a><EFBFBD></td>
<th width="60%" align="center"><EFBFBD></th>
<td width="20%" align="right"><EFBFBD><a href="indexs04.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="sect1">
<a name="kerneloverview"></a><div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="kerneloverview"></a>Linux Kernel Overview</h2></div></div>
<p>This section gives some background to the rest of the document; a very brief overview of the Linux kernel and the key concepts needed to understand its fundamental operation.</p>
<div class="sect2">
<a name="kernel-introduction"></a><div class="titlepage"><div><h3 class="title">
<a name="kernel-introduction"></a>Introduction</h3></div></div>
<p>The kernel can be seen as the heart of an operating system, loaded into RAM at boot time and remaining present until power down, it has two main responsibilities:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46570899"></a>To service low level hardware programming requirements (e.g. responding to hardware interrupts).</p></li>
<li><p>
<a name="id46570904"></a>To provide an environment for processes; instances of programs or threads in execution.</p></li>
</ul></div>
<p>The Linux kernel is said to be monolithic; a single large executable, consisting of several logically divided components.</p>
</div>
<div class="sect2">
<a name="kernel-kernelmodes"></a><div class="titlepage"><div><h3 class="title">
<a name="kernel-kernelmodes"></a>Kernel Modes</h3></div></div>
<p>The kernel can operate in one of two modes: user or kernel. Program execution mainly takes place in user mode, with no direct access to kernel data structures or hardware devices. A switch to kernel mode can be triggered by:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46570927"></a> A program issuing a system call (a library function that makes a request to the kernel).</p></li>
<li><p>
<a name="id46570932"></a> A CPU signaling an exception (an anomalous condition that requires special attention e.g. divide by zero).</p></li>
<li><p>
<a name="id46570937"></a> An interrupt issued to the CPU by a hardware device to indicate that it requires attention.</p></li>
</ul></div>
<p>The kernel spends much of its time in kernel mode running on behalf of a user process. However several threads are executed in kernel mode on behalf of the kernel itself, carrying out &quot;house keeping&quot; activities. Once the pending operation in kernel mode is complete, the kernel switches back to user mode.</p>
</div>
<div class="sect2">
<a name="kernel-modules"></a><div class="titlepage"><div><h3 class="title">
<a name="kernel-modules"></a>Modules</h3></div></div>
<p> The kernel is capable of dynamically loading additional portions of code (modules) on the fly, to enhance its functionality. Amongst other things, modules can add support for file systems or specific hardware devices. When the functionality provided by a module is no longer required, the module can be unloaded, freeing memory.</p>
</div>
<div class="sect2">
<a name="kernel-process"></a><div class="titlepage"><div><h3 class="title">
<a name="kernel-process"></a>Processes</h3></div></div>
<p>A process is an instance of a program in execution. Every process has:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46570970"></a>A state, either runnable, interruptible, uninterruptible, stopped or zombie.</p></li>
<li><p>
<a name="id46570979"></a> A context, a snapshot of all CPU registers (PC, SP, PSW, general purpose, floating point &amp; memory management).</p></li>
<li><p>
<a name="id46570985"></a> A process descriptor, a data structure (of type <tt>task_struct</tt> that holds all the information associated with a process.</p></li>
</ul></div>
<p>The kernel provides a multiprogramming environment; many processes can be active simultaneously. Each process contends for the various hardware resources available. The kernel must ensure that the resources are shared appropriately. Multiprogramming is supported by giving each process in the runnable state queue an opportunity to run on the CPU in turn. The process that &quot;owns&quot; the CPU at a particular instant is referred to as current. The procedure for swapping between runnable processes is termed a context switch. A context switch involves saving the context (a snapshot of the CPU state) of the current process and loading the context of the next runnable process. Context switches can only occur when the kernel is in user mode, so the kernel cannot perform immediate context switches and is termed non-preemptive.</p>
<p>Each user process runs in its own address space, an assigned portion of the total memory available. Address spaces (or parts of) may be shared between processes upon request, or automatically if the kernel deems it appropriate. The separation of the address space of processes prevents one process from interfering with the operation of another or the operating system as a whole.</p>
<p>In addition to the normal user processes running on a system, several kernel threads are created at system startup and run permanently in kernel mode, carrying out various house keeping functions for the kernel.</p>
</div>
<div class="sect2">
<a name="kernel-sync"></a><div class="titlepage"><div><h3 class="title">
<a name="kernel-sync"></a>Synchronisation</h3></div></div>
<p>The kernel is reentrant; several processes may be executing in kernel mode at one time. Of course, on a uniprocessor system only one process can make progress, with all others blocked and waiting in a queue. Example: A process requests a file read. The Virtual File System translates the request into a low level disk operation and passes it to the disk controller, on behalf of the process. Instead of waiting until the disk operation is complete (many thousands of CPU cycles later), the process voluntarily gives up the CPU after making the request and the kernel allows another waiting process to run on the CPU and make progress in kernel mode. When the disk operation is complete (signaled by a hardware interrupt), the current process gives up the CPU to the associated interrupt handler and the original process is woken up, resuming where it left off.</p>
<p>In order to implement a reliable reentrant kernel, care must be taken to ensure the consistency of kernel data structures. If one process modifies a resource counter &quot;behind the back&quot; of another waiting process, the result could be potentially disastrous. The following steps are taken to prevent this type of occurrence:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46571041"></a>One process may only replace another in kernel mode if it has voluntarily relinquished the CPU, leaving data structures in a consistent state, hence the kernel is termed &quot;non-preemptive&quot;.</p></li>
<li><p>
<a name="id46571048"></a>Interrupts may be disabled during critical regions; areas of code that must be completed without interruption.</p></li>
<li><p>
<a name="id46571053"></a>Use of spin locks and semaphores to control access to data structures.</p></li>
</ul></div>
<p>Semaphores consist of the following:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46571061"></a>A counter variable (an integer), initialised to 1.</p></li>
<li><p>
<a name="id46571066"></a> A linked list of processes waiting to access the data structure.</p></li>
<li><p>
<a name="id46571071"></a> Two atomic methods <tt>up()</tt> and <tt>down()</tt> which increment and decrement the counter respectively.</p></li>
</ul></div>
<p>When a kernel control path accesses a data structure protected by a semaphore, it calls <tt>down()</tt>, if the new value of the counter is not negative access is granted, if it is negative access is blocked and the process is added to the semaphore's linked list of waiting processes. Similarly, when a process has finished with a data structure, it calls <tt>up()</tt> and the next process in the waiting list gains access.</p>
<p>Precautions must be taken to ensure deadlock is avoided, where several processes own a single resource, but each is waiting on a resource owned by another waiting process. If this list waiting processes forms a closed circle, deadlock is reached. For an in-depth explanation of deadlock see &quot;The Dining Philosophers Problem&quot; on the Internet or in any computer architecture textbook.</p>
</div>
<div class="sect2">
<a name="kernel-ipc"></a><div class="titlepage"><div><h3 class="title">
<a name="kernel-ipc"></a>Signals and Inter Process Communication</h3></div></div>
<p>A signal is a short message, sent between two processes or between a process and the kernel. Two types of signal are used to notify processes of system events:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46571119"></a>Asynchronous events (e.g. SIGTERM, issued by the Ctrl-C key sequence).</p></li>
<li><p>
<a name="id46571133"></a>Synchronous errors or exceptions (e.g. SIGSEGV when a process attempts to access an illegal address).</p></li>
</ul></div>
<p>There are about 20 different signals defined in the POSIX standard, some of which may be ignored. Some signals cannot be ignored and are not even handled by the process itself.</p>
<p>Linux uses System V Inter-Process-Communication (IPC) which is made up of:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46571144"></a>Semaphores (requested via <tt>semget()</tt> system call).</p></li>
<li><p>
<a name="id46571154"></a>Message queues (received via <tt>msgget()</tt>, sent via <tt>msgsnd()</tt> system calls).</p></li>
<li><p>
<a name="id46571167"></a>Shared memory (requested via <tt>shmget()</tt>, accessed via <tt>shmat()</tt> and relinquished via <tt>shmdt()</tt> system calls).</p></li>
</ul></div>
</div>
<div class="sect2">
<a name="kernel-mm"></a><div class="titlepage"><div><h3 class="title">
<a name="kernel-mm"></a>Memory Management</h3></div></div>
<p>Linux uses virtual memory, a level of abstraction between process memory requests (linear addresses) and the physical addresses used to fulfill them. It makes the following possible:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46571197"></a>Enables processes to run whose total memory requirements exceed the physical RAM available.</p></li>
<li><p>
<a name="id46571202"></a>A continuous address space, independent of physical memory organisation.</p></li>
<li><p>
<a name="id46571207"></a>Demand paging; portions of data or code are only loaded into RAM when required.</p></li>
<li><p>
<a name="id46571212"></a>Shared images of programs and libraries, making memory use more efficient.</p></li>
<li><p>
<a name="id46571216"></a>Transparent relocation of running programs in memory.</p></li>
</ul></div>
<p>The address space is divided into 4kB portions called &quot;pages&quot;, which form the basic unit of all virtual memory transactions. Physical RAM is also divided into 4kB portions called &quot;page frames&quot;, each of which can store any arbitrary page. Because the total address space exceeds that of the RAM available, only a subset of all the available pages can be held in RAM at one time. However, a page must be present in RAM for it to be accessed as data or executed as a program.</p>
<p>Because any page can be relocated in any page frame, the kernel must keep track of where the used pages are kept. This is implemented using page tables, which are used to convert logical addresses into physical ones.</p>
<p>On Intel x86 hardware, Linux actually uses a two level page table scheme (but uses a three level scheme internally to improve portability) to reduce the amount of memory taken up by page tables. To convert a linear address into a physical one, the tables are consulted in this order: Page Global Directory then Page Table to yield a page number and an offset within the page. Therefore, a linear address can be broken down into three parts: Directory, Table and Offset. Because Linux 2.2 can address 4GB of address space (using 32 bit addresses) and uses a 4kB page size, the 10 most significant bits of an address make up the Directory, the next 10 most significant bits make up the Table (hence identify the page required) and the 12 least significant bits make up the offset from the start of the page.</p>
</div>
<div class="sect2">
<a name="kernel-vfs"></a><div class="titlepage"><div><h3 class="title">
<a name="kernel-vfs"></a>Virtual File system</h3></div></div>
<p>The VFS is responsible for providing a common interface to all underlying file systems present on a system; &quot;The Common File Model&quot; which is capable of representing files on any type of file system. The file systems supported by the VFS fall into three categories:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46571265"></a>Disk based, including hard disk, floppy disk and CD-ROM.</p></li>
<li><p>
<a name="id46571270"></a>Network based, including NFS, AFS and SMB.</p></li>
<li><p>
<a name="id46571275"></a>Special file systems, including <tt>/proc</tt> and <tt>/dev/pts</tt>.</p></li>
</ul></div>
<p>The common file model can be viewed as object-oriented, with objects being software constructs (data structures and associated methods/functions) of the following types:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46571293"></a>Super block object; stores information relating to a mounted file system, corresponding to a file system control block stored on disk (for disk based file systems).</p></li>
<li><p>
<a name="id46571299"></a>Inode object; stores information relating to a single file, corresponding to a file system control block stored on disk (for disk based file systems).</p></li>
<li><p>
<a name="id46571304"></a>File object; stores information relating to the interaction of an open file and a process. This object exists while a process is interacting with a file.</p></li>
<li><p>
<a name="id46571310"></a>Dentry object; links a directory entry (a pathname) with its corresponding inode on disk.</p></li>
</ul></div>
<p>Recently used dentry objects are held in a dentry cache to speed up the translation from a pathname to the inode of the corresponding file. The dentry cache consists of two types of data structure:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46571320"></a>Dentry objects in the following states: in use, unused or negative.</p></li>
<li><p>
<a name="id46571325"></a>A hash table to speed up pathname to inode translation.</p></li>
</ul></div>
</div>
<div class="sect2">
<a name="kernel-diskcache"></a><div class="titlepage"><div><h3 class="title">
<a name="kernel-diskcache"></a>Disk Caches</h3></div></div>
<p>**FIXME** This section needs updating for 2.4.x kernels.</p>
<p>Linux dynamically sets aside a certain proportion of the available memory for two disk caches; the buffer cache and the page cache. Use of caches increases system performance by minimising the number of time consuming disk access required.</p>
<div class="sect3">
<a name="kernel-buffercache"></a><div class="titlepage"><div><h4 class="title">
<a name="kernel-buffercache"></a>The Buffer Cache</h4></div></div>
<p>The buffer cache is made up of lots of buffers, each of which refer to a single arbitrary block on a block device. Each buffer consists of a <tt>buffer_head</tt> data structure and an area of memory equal to the block size of the associated device, used to hold data.</p>
<p>To minimise the CPU overhead involved in maintaining the buffer cache, all the buffers are held in one of several linked lists. Each of the linked lists contains buffers in the same state; unused, free, clean, dirty, locked etc.</p>
<p>In order to gain a significant performance benefit using a cache, the process of checking the buffer cache for a particular buffer must be as efficient as possible. Every time a call to <tt>read()</tt> is made, the buffer cache must be checked for the required block(s) first. To enable buffers to be found quickly, a hash table is maintained, containing all the buffers present in the cache. The <tt>getblk()</tt> function is the main service routine for the buffer cache; it performs the functions described above.</p>
<p>The buffer cache can also be used to improve the disk writing performance of the system. Instead of carrying out all writes immediately, the kernel stores data to be written in the buffer cache, waiting to see if the writes can be grouped together to minimise disk head movement. A buffer that contains data that is waiting to be written to disk is termed &quot;dirty&quot;. A field in the buffer head data structure indicates if a particular page is dirty or not.</p>
</div>
<div class="sect3">
<a name="kernel-pagecache"></a><div class="titlepage"><div><h4 class="title">
<a name="kernel-pagecache"></a>The Page Cache</h4></div></div>
<p>The page cache is made up of pages, each of which refers to a 4kB portion of data associated with an open file. The data contained in a page may come from several disk blocks, which may not be next to each other on the disk. The page cache is largely used to interface the requirements of the memory management subsystem (which uses fixed, 4kB pages) to the VFS subsystem (which uses variable size blocks).</p>
<p>The page cache has two important data structures, a page hash table and an inode queue. The page hash table is used to quickly find the page descriptor of the page holding data associated with an inode and offset within a file. The inode queue contains lists of page descriptors relating to open files.</p>
<p>The three main service routines for the page cache are <tt>find_page()</tt>, <tt>add_to_page_cache()</tt> and <tt>remove_inode_page()</tt>.</p>
<p>Special care must be taken to synchronise the two caches, to prevent processes from receiving stale data. Should the kernel become short on memory, memory can be reclaimed by emptying the disk caches of old, unused data. This task is performed by a dedicated kernel thread.</p>
</div>
</div>
<div class="sect2">
<a name="overviewyourturn"></a><div class="titlepage"><div><h3 class="title">
<a name="overviewyourturn"></a>Your Turn</h3></div></div>
<p>Head over to **FIXME** lxr and look up some of the functions mentioned in this chapter. Get used to using lxr and moving around the source code. If possible, try and understand the code, but don't panic if it doesn't make a lot of sense at this stage!</p>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a href="indexs02.html">Prev</a><EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Home</a></td>
<td width="40%" align="right"><EFBFBD><a href="indexs04.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left">Structure<EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Up</a></td>
<td width="40%" align="right"><EFBFBD>Source Tour</td>
</tr>
</table>
</div>
</body>
</html>

107
docs/kernelhacking-HOWTO/indexs04.html Normal file
View File

@@ -0,0 +1,107 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<title>Source Tour</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.40">
<link rel="home" href="index.html" title="Kernel Hacking HOWTO">
<link rel="up" href="index.html" title="Kernel Hacking HOWTO">
<link rel="previous" href="indexs03.html" title="Linux Kernel Overview">
<link rel="next" href="indexs05.html" title="Tools">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Source Tour</th></tr>
<tr>
<td width="20%" align="left">
<a href="indexs03.html">Prev</a><EFBFBD></td>
<th width="60%" align="center"><EFBFBD></th>
<td width="20%" align="right"><EFBFBD><a href="indexs05.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="sect1">
<a name="sourcetour"></a><div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="sourcetour"></a>Source Tour</h2></div></div>
<p>The kernel source is made up of around two million lines of code. While that may seem intimidating, it is important to remember that very few people understand all the subsystems and associated source code in depth. You can improve your programming productivity if you know where to look for specific code, down to a directory and a source file.</p>
<div class="sect2">
<a name="whatgoeswhere"></a><div class="titlepage"><div><h3 class="title">
<a name="whatgoeswhere"></a>What goes where</h3></div></div>
<p>Fortunately, the source is well organised into a logical directory structure. This section gives a quick guide to the top level kernel source directory:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46571473"></a><tt>Documentation</tt>: Information about specific platforms &amp; devices as well as general kernel information.</p></li>
<li><p>
<a name="id46571466"></a><tt>arch</tt>: Architecture specific code; i386, sparc etc.</p></li>
<li><p>
<a name="id46571489"></a><tt>drivers</tt>: Device specific code; sound card, network card etc.</p></li>
<li><p>
<a name="id46571496"></a><tt>fs</tt>: Filesystem specific code; ext2, vfat etc.</p></li>
<li><p>
<a name="id46571504"></a><tt>include</tt>: Kernel header files.</p></li>
<li><p>
<a name="id46571511"></a><tt>init</tt>: All the code associated with the boot and initialisation process.</p></li>
<li><p>
<a name="id46571518"></a><tt>IPC</tt>: Inter Process Communication code; shared memory implementation etc.</p></li>
<li><p>
<a name="id46571525"></a><tt>kernel</tt>: The core kernel code; scheduling, signals etc.</p></li>
<li><p>
<a name="id46571533"></a><tt>libs</tt>: Kernel related libraries; image decompression etc.</p></li>
<li><p>
<a name="id46571540"></a><tt>mm</tt>: Memory Management related code.</p></li>
<li><p>
<a name="id46571547"></a><tt>net</tt>: Network related code.</p></li>
<li><p>
<a name="id46571554"></a><tt>scripts</tt>: kernel related scripts (e.g. patch-kernel)</p></li>
</ul></div>
</div>
<div class="sect2">
<a name="keydatastructures"></a><div class="titlepage"><div><h3 class="title">
<a name="keydatastructures"></a>Key data structures</h3></div></div>
<p>This section gives a quick guide to some of the fundamental data structures, including key fields and where to find them in the kernel source tree.</p>
<div class="sect3">
<a name="processdescriptor"></a><div class="titlepage"><div><h4 class="title">
<a name="processdescriptor"></a>Process descriptor</h4></div></div>
<p>Process Descriptor: <tt>task_struct</tt>: <tt>~/include/linux/sched.h:281</tt>
</p>
</div>
<div class="sect3">
<a name="pagedescriptor"></a><div class="titlepage"><div><h4 class="title">
<a name="pagedescriptor"></a>Page descriptor</h4></div></div>
<p>Page Descriptor:</p>
</div>
</div>
<div class="sect2">
<a name="startingpoints"></a><div class="titlepage"><div><h3 class="title">
<a name="startingpoints"></a>Starting Points</h3></div></div>
<p>This section will present a selection of good starting points for reading and understanding the kernel source code.</p>
</div>
<div class="sect2">
<a name="srctouryourturn"></a><div class="titlepage"><div><h3 class="title">
<a name="srctouryourturn"></a>Your Turn</h3></div></div>
<p>Find and read the driver code for some of the devices in your system.</p>
<p>Take a look at the <tt>Makefiles</tt> and see if you can figure out how the build process works. See <tt>Documentation/kbuild/makefiles.txt</tt> for help.</p>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a href="indexs03.html">Prev</a><EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Home</a></td>
<td width="40%" align="right"><EFBFBD><a href="indexs05.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left">Linux Kernel Overview<65></td>
<td width="20%" align="center"><a href="index.html">Up</a></td>
<td width="40%" align="right"><EFBFBD>Tools</td>
</tr>
</table>
</div>
</body>
</html>

399
docs/kernelhacking-HOWTO/indexs05.html Normal file
View File

@@ -0,0 +1,399 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<title>Tools</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.40">
<link rel="home" href="index.html" title="Kernel Hacking HOWTO">
<link rel="up" href="index.html" title="Kernel Hacking HOWTO">
<link rel="previous" href="indexs04.html" title="Source Tour">
<link rel="next" href="indexs06.html" title="Tasks">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Tools</th></tr>
<tr>
<td width="20%" align="left">
<a href="indexs04.html">Prev</a><EFBFBD></td>
<th width="60%" align="center"><EFBFBD></th>
<td width="20%" align="right"><EFBFBD><a href="indexs06.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="sect1">
<a name="tools"></a><div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="tools"></a>Tools</h2></div></div>
<p>This section aims to explain the development tools that are fundamental to the kernel development process.</p>
<div class="sect2">
<a name="editors"></a><div class="titlepage"><div><h3 class="title">
<a name="editors"></a>Editors</h3></div></div>
<p>There is a wide choice when it comes to choosing an editor. Many heated debates have taken place over which editor(s) is best suited to (kernel) programming. In order to appease both sides and to give a balanced view, both vim and emacs will be presented here! The idea is help the undecided programmer figure out which editor best suits his or her needs.</p>
</div>
<div class="sect2">
<a name="vim"></a><div class="titlepage"><div><h3 class="title">
<a name="vim"></a>vim</h3></div></div>
<p>Just about every UNIX-like system has at least vi available, if not vim (vi-improved) which has some extra, tasty features like syntax highlighting.</p>
<p>Reasons to use vim for kernel programming:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46571700"></a>Integrates really nicely with ctags. If you <b>make tags</b> in the top level kernel source directory, you can then quickly access function &amp; variable definitions by pressing Ctrl-] while the cursor is over the function or variable in question.</p></li>
<li><p>
<a name="id46571725"></a>Auto-completion of variable and function names can save edit-compile cycles by reducing spelling mistakes. This particularly applies to kernel programming as some of the function names are quite long and involved. To use this feature, type the first part of the variable or function and press Ctrl-P repeatedly to search backwards through the document for possible matches.</p></li>
<li><p>
<a name="id46571740"></a>Fast loading time.</p></li>
<li><p>
<a name="id46571743"></a>Small memory footprint; leaves more memory for kernel recompiles.</p></li>
<li><p>
<a name="id46571748"></a>Highly configurable. Amongst other things, command keystrokes are easily re-mapped; useful if you find a common command awkward or uncomfortable.</p></li>
<li><p>
<a name="id46571753"></a>As of version 6.0, integrates with cscope as well. (Thanks to Bohdan Vlasyuk for this addition)</p></li>
</ul></div>
<p>Other reasons to use vim:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46571770"></a>If you can use vim, you will always have an editor to hand. Even the most basic rescue boot disks have at least vi. In short, one day you'll need to know how to use it, be it sooner or later! The more proficient you are, the less painful that experience will be.</p></li>
<li><p>
<a name="id46571782"></a>The keyboard shortcuts involve less hand movement, for an unmodified key map at least.</p></li>
</ul></div>
<p>Reasons not to use vim</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46571792"></a>Constant use of the (poorly positioned) <b>Esc</b> key reduces typing efficiency. Possible solutions involve i) pressing Ctrl-[ instead ii) re-mapping a more ergonomic key to be <b>Esc</b>.</p></li>
<li><p>
<a name="id46571815"></a>vim is linked against a lot of libraries: (<b>ldd /usr/bin/vim</b> to see the list) including some X libraries. If this is a real concern, you may prefer vi.</p></li>
<li><p>
<a name="id46571831"></a>Some people really don't get on with the modal way of doing things.</p></li>
</ul></div>
<p>Probably the best way to learn the basics of vim is to follow the tutorial; start vimtutor and enjoy. The <a href="http://www.linuxdoc.org/HOWTO/Vim-HOWTO.html" target="_top">vim-HOWTO</a> also has a lot of useful information.</p>
<p>For additional information on editing C source code with vim, see the <a href="http://www.linuxdoc.org/HOWTO/C-editing-with-VIM-HOWTO/index.html" target="_top">C-editing-with-Vim-HOWTO</a>
</p>
<p>For more general information on vim see <a href="http://www.vim.org" target="_top">the Vim Homepage</a>
</p>
</div>
<div class="sect2">
<a name="emacs"></a><div class="titlepage"><div><h3 class="title">
<a name="emacs"></a>emacs</h3></div></div>
<p><i>Most of the information in this section is also applicable to xemacs.</i></p>
<p>Like vi, emacs also has a long heritage and a large number of loyal users.</p>
<p>Reasons to use emacs for kernel programming:</p>
<div class="itemizedlist"><ul><li><p>
<a name="id46571896"></a>Large library of emacs lisp programs available to aid productivity.</p></li></ul></div>
<p>Other reasons to use emacs</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46571905"></a>Good integration with etags.</p></li>
<li><p>
<a name="id46571915"></a>Also integrates with grep and cscope.</p></li>
<li><p>
<a name="id46571927"></a>gdb integration.</p></li>
<li><p>
<a name="id46571934"></a>The keystrokes may seem more intuitive (e.g. you can type into a document immediately without having to enter a mode), and therefore maybe preferred by those who don't get on with the modal way of doing things.</p></li>
</ul></div>
<p>Reasons not to use emacs</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46571944"></a>Constant use of the <b>Ctrl</b> key makes RSI a real concern. Re-mapping <b>Caps-Lock</b> to be another <b>Ctrl</b> key is recommended.</p></li>
<li><p>
<a name="id46571962"></a>It is a big package so may not be suitable for systems with limited hard disk space.</p></li>
<li><p>
<a name="id46571966"></a>Longer loading time on modest systems.</p></li>
<li><p>
<a name="id46571970"></a>Larger memory footprint, so less memory available for kernel recompiles.</p></li>
<li><p>
<a name="id46571975"></a>etags is considered unstable by some, dumping core frequently.</p></li>
</ul></div>
<p>One of the best ways to learn emacs is to work through the tutorial which can be accessed by loading emacs and issuing these keystrokes: Ctrl-h then <b>t</b>.</p>
<p>If you like the way that emacs works but don't like it's size, you could try jove which is a minimal clone. The source can be downloaded from <a href="ftp://ftp.cs.toronto.edu/pub/moraes/jove/" target="_top">the jove FTP site.</a>
</p>
<p>For more information on emacs see <a href="http://www.gnu.org/software/emacs/" target="_top">the emacs home page.</a>
</p>
<p>In summary, if you like to do <i>everything</i> in one place (write code, debug code, review patches, email, news groups), emacs is probably for you. If you like smaller, more application specific programs, a smaller editor (like vim) may suit you better.</p>
</div>
<div class="sect2">
<a name="development"></a><div class="titlepage"><div><h3 class="title">
<a name="development"></a>Development</h3></div></div>
<div class="sect3">
<a name="make"></a><div class="titlepage"><div><h4 class="title">
<a name="make"></a>make</h4></div></div>
<p>make is a program that is used to determine which parts of a multi-source-file project need to be rebuilt. Only those source files which have been modified are rebuilt before the final linking step. This is a big plus for the kernel programmer as once the &quot;stock&quot; kernel has been built, recompiles to include changes take seconds instead of minutes. make operates on a <tt>Makefile</tt>, a file containing the relationships and dependencies between source files along with the commands used to build them.</p>
<p>Just about every directory in the kernel source tree has a makefile, including the top level directory. When you invoke <b>make dep bzImage modules</b>, make operates on the top level makefile which recursively works through the makefiles in each of the subdirectories (depending on which options were included during the config step).</p>
</div>
<div class="sect3">
<a name="lclint"></a><div class="titlepage"><div><h4 class="title">
<a name="lclint"></a>lclint</h4></div></div>
<p>Some programming errors can be caught early on in the development cycle, saving time and effort. You may not have bothered with formal code analysis before, but now would be a good time to start; bugs in kernel code are generally harder to track down and can have more serious implications than their user-space counterparts. Generally speaking, a higher standard of programming is called for; while a user may be prepared to put up with an email client that occasionally core dumps, they certainly won't put up with a kernel that freezes or worse, causes data loss.</p>
<p>lclint is a program that can be used to statically check C code, that is to check it before it is even compiled or executed. Like lint, lclint can be run on unmodified C source code and used to catch classic programming mistakes. However, lclint can do a whole lot more for you, but you must give it &quot;clues&quot; by annotating your source code using comments in the appropriate way.</p>
<p>In short, lclint can give you some of the foresight that an experienced programmer has at their disposal. While it may not be perfectly suited to kernel C code (which has some unusual attributes), it can still be used to prove fragments of code prior to inclusion in the kernel source.</p>
<p>More information on lclint can be found at <a href="http://lclint.cs.virginia.edu/" target="_top">the lclint home page.</a>
</p>
</div>
</div>
<div class="sect2">
<a name="srccodenav"></a><div class="titlepage"><div><h3 class="title">
<a name="srccodenav"></a>Source Code Navigation</h3></div></div>
<p>One of the most daunting activities that faces a new kernel programmer is navigating a very large volume of unfamiliar source code. This section describes some invaluable tools to help.</p>
<div class="sect3">
<a name="grep"></a><div class="titlepage"><div><h4 class="title">
<a name="grep"></a>grep</h4></div></div>
<p>grep is used to find lines matching a given pattern; a useful tool for quickly locating variable or function definitions and use. Example: Suppose you want to find all instances of <tt>task_struct</tt>:</p>
<p><b>$grep -r task_struct * | less</b></p>
<p>This command recursively (<b>-r</b>) scans all files in the source tree and prints lines containing <tt>task_struct</tt>, those lines are piped to less, which provides a scroll-able output. <b>man grep</b> for more details!</p>
</div>
<div class="sect3">
<a name="lxr"></a><div class="titlepage"><div><h4 class="title">
<a name="lxr"></a>lxr</h4></div></div>
<p>lxr enables you to navigate source code via a web browser, where all variables and functions are links to their respective definitions. Probably the best way to read and understand code.</p>
<p>You can browse the kernel source code online at <a href="http://lxr.linux.no/source/?v=2.4.16" target="_top">the Linux Cross Reference Page</a> or at <a href="http://innominate.org/cgi-bin/lksr/" target="_top">innominate.org</a>, or download lxr and set it up on your box, useful if you don't have a permanent Internet connection. The setup process is quite involved but details are given in the README file that comes with the lxr source code.</p>
</div>
<div class="sect3">
<a name="cscope"></a><div class="titlepage"><div><h4 class="title">
<a name="cscope"></a>cscope</h4></div></div>
<p>cscope is useful for doing many of the things you could use grep for, but is more intelligent and provides a nicer interface to work with. You can search for definitions, uses, strings etc.</p>
<p>Before you can use cscope you need to build an index file. This can be done by issuing the command <b>cscope -b -R -k</b> in the top level source directory; <b>-b</b> to build the index, <b>-R</b> to search recursively through the source tree and <b>-k</b> to indicate kernel use; this ensures the appropriate include files are used when generating the index.</p>
<p>To start a cscope session, type <b>cscope -d</b>. You will then get something that looks like this:</p>
<pre class="screen">
Cscope version 15.3 Press the ? key for help
Find this C symbol:
Find this global definition:
Find functions called by this function:
Find functions calling this function:
Find this text string:
Change this text string:
Find this egrep pattern:
Find this file:
Find files #including this file:
</pre>
<p>The top half of the screen is used to display search results, while the lower half is used to issue commands. Example; suppose you want to find the definition of the file_system_type data structure. Use the arrow keys to move the cursor to the Find this global definition: field and enter the name of the data structure, followed by enter. If all is well, cscope will find just one instance and will open your favourite editor (set by the <b>EDITOR</b> environment variable) to display the appropriate section of the file.</p>
<p>Now suppose you want to find the definition of <tt>super_block</tt>. Follow the procedure above, which should give you this output:</p>
<pre class="screen">
Global definition: super_block
File Line
0 vxfs_extern.h 44 struct super_block;
1 super.c 265 int (*test)(struct super_block *, struct buffer_head *);
2 udfdecl.h 52 struct super_block;
3 fs.h 688 struct super_block
4 fs.h 936 struct super_block *(*read_super) (struct super_block *,
void *, int );
5 udf_fs_sb.h 71 __u32 (*s_partition_func)(struct super_block *, __u32,
__u16, __u32);
Find this C symbol:
Find this global definition:
Find functions called by this function:
Find functions calling this function:
Find this text string:
Change this text string:
Find this egrep pattern:
Find this file:
Find files #including this file:
</pre>
<p>This time, cscope has found multiple possible definitions. You can view each definition in its context by pressing the numbers given next to the list of files, alternatively, you can use <b>Tab</b> to move to the top half of the screen and the arrow keys to select a definition. Simply quit out of the editor to return to cscope. Press <b>Tab</b> again to return to the command area. Note that you can also move up and down using Ctrl-p and Ctrl-n, which saves moving your hands away from a typing position. To exit cscope, press Ctrl-d.</p>
<p>cscope source code and documentation is available from <a href="http://cscope.sourceforge.net/" target="_top">the cscope home page</a>, I would advise using version 15.3 or later as this version includes support for recursive indexing and using kernel headers.</p>
</div>
<div class="sect3">
<a name="ctags"></a><div class="titlepage"><div><h4 class="title">
<a name="ctags"></a>ctags</h4></div></div>
<p>ctags provides similar functionality to cscope, but integrates closely with your editor, allowing look-ups with a few key strokes. Like cscope, ctags builds an index file to speed up searches. The easiest way to generate the index is to type <b>make tags</b> in the top level kernel source directory.</p>
<p>When using vim, moving the cursor to a use of a function/variable/data structure/type and pressing Ctrl-] should take you to the definition. Ctrl-t takes you back to where you were. Note that lookups can be nested, in which case, Ctrl-t takes you up one level.</p>
<p>Details for using ctags with emacs are welcome!</p>
<p>ctags can be obtained from <a href="http://ctags.sourceforge.net/" target="_top">the ctags home page</a>. Debian users will want to install the exuberant-ctags package.</p>
</div>
<div class="sect3">
<a name="summary"></a><div class="titlepage"><div><h4 class="title">
<a name="summary"></a>Summary</h4></div></div>
<p>A brief summary of the tools presented:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46572491"></a>lxr is useful for browsing and understanding code, as opposed to editing.</p></li>
<li><p>
<a name="id46572499"></a>cscope is useful for finding a definition if you know the name of function/variable/data structure concerned and want quick access to the source file, perhaps to add a field to a data structure.</p></li>
<li><p>
<a name="id46572509"></a>ctags is useful for doing quick look-ups during an editing session, but isn't quite as smart as cscope is.</p></li>
</ul></div>
</div>
</div>
<div class="sect2">
<a name="sourcecodemanipulation"></a><div class="titlepage"><div><h3 class="title">
<a name="sourcecodemanipulation"></a>Source Code Manipulation</h3></div></div>
<div class="sect3">
<a name="diff"></a><div class="titlepage"><div><h4 class="title">
<a name="diff"></a>diff</h4></div></div>
<p>diff is used to compare two files and output any differences between them. When used in unified mode (<b>-u</b> option) to compare two files (original and modified) a &quot;patch&quot; is produced:</p>
<p><b>diff -u linux-2.4.14/drivers/char/keyboard.c linux/drivers/char/keyboard.c &gt; my_keyboard_patch</b></p>
<p>Where the <tt>linux-2.4.14</tt> directory holds the original, unmodified source tree and <tt>linux</tt> directory holds the one you have hacked around with. Distribution of ideas and modifications as patches is a lot more convenient and efficient than distributing complete files or source trees.</p>
<p>The procedure above can be used when just one file has been modified, but what if you need to modify a lot files and produce a patch?</p>
<p><b>diff -urN linux-2.4.14 linux &gt; my_hefty_kernel_patch</b></p>
<p>Note that the convention is to generate patches from the directory above the top level kernel source directory i.e. <tt>/usr/src</tt> if you keep your modified kernel source in <tt>/usr/src/linux</tt>.</p>
<p>Note that if you are generating a patch to post to the Linux Kernel Mailing List, be sure to follow the instructions given in the FAQ exactly. The FAQ can be found at: <a href="http://www.tux.org/lkml/" target="_top">http://www.tux.org/lkml/</a>
</p>
<p>Of course, use of diff is not restricted to generating patches; it is a useful tool for finding out what has changed between two kernel releases. Uncompressed patches are human readable to some extent; the format is fairly self explanatory. You can even grep a patch if you know what you are looking for.</p>
</div>
<div class="sect3">
<a name="patch"></a><div class="titlepage"><div><h4 class="title">
<a name="patch"></a>patch</h4></div></div>
<p>patch is used to apply patches to a file or a source tree:</p>
<p>
<b>cd linux-2.4.13</b><b>patch -p1 patch-2.4.14</b>
</p>
<p>This procedure would update a 2.4.13 tree to 2.4.14. The <b>-p1</b> option strips the top level directory off all filenames within the patch (as you are patching from inside the top level source directory). Of course, you could apply the patch from the directory above, but you would need to have your directories named in the same way as when the patch was generated. Note that patches are often distributed in compressed form, to save bandwidth. You can save disk space (and typing) by uncompressing patches as you apply them:</p>
<p><b>bzip2 -dc /usr/src/patch-2.4.14.bz2 | patch -p1</b></p>
<p>Simply replace bzip2 with gzip if the patch was gzipped instead of bzipped.</p>
<p>A useful script is included in the kernel source tree to semi-automate the process of upgrading a source tree by applying successive patches: <tt>linux/scripts/patch-kernel</tt>. Read the script to see what it does and how to use it, instructions are given in the comments at the top of the file.</p>
<p>It is often a good idea to do a &quot;dry run&quot; of applying a patch, especially if you are patching a heavily modified tree, or are attempting to apply an old patch against a newer tree. Backing out a partially applied patch can be time consuming and generally is not much fun!</p>
<p><b>bzip2 -dc /usr/src/patch-2.4.14.bz2 | patch -p1 --dry-run</b></p>
<p>What if the patch does not apply cleanly? If only a couple of files failed, you could apply the patch anyway and sort things out with a text editor afterwards, alternatively you could manually go through and apply the patch by reading it and making the changes by hand. The manual approach is sometimes necessary to resolve conflicting patches and is a useful technique if you want to understand exactly what a patch changes.</p>
<p>What if you want to remove a previously applied patch? Easy:</p>
<p><b>bzip2 -dc /usr/src/patch-2.4.14.bz2 | patch -R -p1</b></p>
<p>This would take your source tree back to 2.4.13.</p>
</div>
<div class="sect3">
<a name="RCS"></a><div class="titlepage"><div><h4 class="title">
<a name="RCS"></a>RCS</h4></div></div>
<p>Any development work is an incremental process, particularly so at the debugging stage. It always pays to keep a record of the process using some form of revision control system, so that a bad change can backed out with minimal effort. A very basic revision control system can be implemented by just keeping a backup of a file before making major changes, however this approach tends to become cumbersome very quickly.</p>
<p>Enter RCS, the little brother of CVS. CVS is great for large projects with many contributors, but is overkill for small personal projects. One of the attractions of RCS is it's simplicity.</p>
<p>First create the <tt>RCS</tt> directory in the same directory as your source files:</p>
<p><b>mkdir RCS</b></p>
<p>Then &quot;check in&quot; a source file:</p>
<p><b>ci -u some-file.c</b></p>
<p>You will then be prompted to give a description. By default, RCS deletes the working file upon check in, so you will want the <b>-u</b> option which automatically checks the file out again. Check in all the files you are working on in this way.</p>
<p>Make some changes to one of your source files and check it in again. You'll be prompted for a summary of the changes and the version number will be incremented.</p>
<p>Suppose you have made a mess of the working file and want to revert to a known good version (1.7), check it out using this command:</p>
<p><b>co -l -r1.7 some-file.c</b></p>
<p>The <b>-l</b> flag locks the file and gives you write access to it (otherwise you get read access only).</p>
<p>RCS stores the initial file and only differences between versions, saving disk space. For more information on RCS, see the following man pages: rcs, ci, co, rcsintro, rcsdiff, rcsclean, rcsmerge, rlog, rcsfile and ident.</p>
</div>
<div class="sect3">
<a name="CVS"></a><div class="titlepage"><div><h4 class="title">
<a name="CVS"></a>CVS</h4></div></div>
<p>While RCS is good for basic projects involving (changes to) a limited number of files, it quickly becomes unwieldy for larger projects, particularly so with contributions from more than one developer. CVS is particularly good in this area.</p>
<div class="sect4">
<a name="cvscommands"></a><div class="titlepage"><div><h5 class="title">
<a name="cvscommands"></a>CVS Commands</h5></div></div>
<p>All cvs commands are specified as sub-commands of the <b>cvs</b> command. Both the <b>cvs</b> command and the sub-command can be passed options, but their position in the command line should be as shown here.</p>
<p><b>$ cvs [cvs options] sub-command [sub-command options]</b></p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46572858"></a><b>add</b>: This command will add a new file to source control. You must check in the file using <b>cvs ci</b> after this command to make the change take effect.</p></li>
<li>
<p>
<a name="id46572871"></a><b>ci</b> or <b>commit</b>: This command will check in the changes that you have made to the local copy of a file to make them permanent. After this command, anyone updating or checking out the file from the repository will see the changes that you have made. You can either specify the <b>-m</b> &quot;message&quot; option to provide a message describing the change, or this command will execute the editor for you to enter the message.</p>
<p>When you check in your changes and the local copy of the files are not up to date, cvs will print a message informing you of this. In this case, you have to update the files and then check in your changes.</p>
<p>To check in the changes in all the modified files in the current working directory, execute the following command from the top of the working directory:</p>
<p><b>$ cvs -q ci -m &quot;blah blah ...&quot;</b></p>
</li>
<li><p>
<a name="id46572907"></a><b>co</b> or <b>checkout</b>: This command will make a local copy of all the files in a module. First, it will create a subdirectory with the same name as the module, then it will copy the files into that subdirectory.</p></li>
<li>
<p>
<a name="id46572920"></a><b>diff</b>: This command will print the differences between the local copy of a file and the version in the repository.</p>
<p>To generate a patch for the changes in the current working directory, execute the following command from the top of the working directory.</p>
<p><b>$ cvs -q diff -u</b></p>
</li>
<li>
<p>
<a name="id46572936"></a><b>history</b>: This command will print information about the <b>cvs</b> repository. By default, this command only prints information that pertains to you. You can use the <b>-a</b> option to print information about all users. The following are some useful history options.</p>
<p>
<b>$ cvs history -a -o # Show checked out files</b><b>$ cvs history -a -T # Show all tags</b><b>$ cvs history -a -e # Show all information</b>
</p>
</li>
<li>
<p>
<a name="id46572964"></a><b>import</b> This command will put an existing project into the repository.</p>
<p><b>$ cvs import -m &quot;blah blah ...&quot; directory vendorTag releaseTag</b></p>
</li>
<li><p>
<a name="id46572976"></a><b>log</b>: This command will print the messages that were specified when each file was checked in.</p></li>
<li>
<p>
<a name="id46572983"></a><b>remove</b>: This command will remove a file from source control. You must check in the file using cvs ci after this command to make the change take effect???</p>
<p>This command will remove a file from the current branch of the source tree. If someone checks out the module, they will not get a copy of this file. However, if they check out an older version of the module, they will still get the appropriate version of the file.</p>
</li>
<li>
<p>
<a name="id46572996"></a><b>tag</b>: To tag all the files in the current working directory, execute the following command from the top of the working directory.</p>
<p><b>$ cvs -q tag tagName</b></p>
</li>
<li>
<p>
<a name="id46573009"></a><b>update</b>: This command will update the local copy of the files in a module. For any file that is updated, its name is printed preceded by a &quot;U&quot;. It will also print the names of the files that you have modified (i.e., files that are different from the copy in the repository) and precede them with an &quot;M&quot;.</p>
<p>If there is a conflict between a file that needs to be updated and the local changes that you have made, the file name will be printed and it will be preceded with a &quot;C&quot;. The file will be replaced and the conflicting code will be marked with &quot;&quot; and &quot;&gt;&gt;&gt;&gt;&quot;, and the original file will be saved as .#file.version.</p>
<p>You can always delete your local copy of a file and use the cvs update command to restore the up-to-date copy of the file from the repository. In this case, CVS will print a message that the file was lost and replace the file. The file name will be printed preceded by a &quot;U&quot;.</p>
<p>To list the files that have been modified in the current working directory, execute the following command from the top of the working directory.</p>
<p><b>$ cvs -q update</b></p>
</li>
</ul></div>
</div>
<div class="sect4">
<a name="repspec"></a><div class="titlepage"><div><h5 class="title">
<a name="repspec"></a>Repository Specification</h5></div></div>
<p> The cvs repository is specified using the <b>-d</b> option to the <b>cvs</b> command or the <b>CVSROOT</b> environment variable. For example,</p>
<p><b>$ cvs -d pathName login</b></p>
<p>Or,</p>
<p>
<b>$ export CVSROOT=pathName</b><b>$ cvs login</b>
</p>
<p>If the repository is on the local system, the option is simply the path to the repository. For example,</p>
<p><b>$ export CVSROOT=/usr/local/cvs</b></p>
<p>However, if the repository is on another system, the repository specification must also include the access method and the user name and server name where the repository is located. Each of these items; the access method, user name and server name, and the path name of the repository on the server; must be separated by a colon. The user name and the server name are connected with the at-sign (&quot;@&quot;).</p>
<p><b>$ export CVSROOT=:accessMethod:userName@serverName:pathName</b></p>
<p>Linux Top of Tree (2.4)</p>
<p> To get the Linux source code for Linux 2.4, use the following command. This repository is a mirror that is updated every 30 minutes.</p>
<p>
<b>$ export CVSROOT=:pserver:cvs@vger.samba.org:/vger</b><b>$ cvs login</b><b>Password: cvs</b><b>$ cd some-directory # For example, /usr/local/src</b><b>$ cvs -z3 co linux</b>
</p>
<p>To update the source code, use the following commands.</p>
<p>
<b>$ cd some-directory/linux</b><b>$ cvs -z3 update -d</b>
</p>
<p>Linux Branch (2.2)</p>
<p>Or, to get the Linux 2.2 source code, use the following command</p>
<p>
<b>$ export CVSROOT=:pserver:cvs@vger.samba.org:/vger</b><b>$ cvs login</b><b>Password: cvs</b><b>$ cd some-directory # For example, /usr/local/src</b><b>$ cvs -z3 co -r linux_2_2 linux</b>
</p>
</div>
</div>
</div>
<div class="sect2">
<a name="toolsyourturn"></a><div class="titlepage"><div><h3 class="title">
<a name="toolsyourturn"></a>Your Turn</h3></div></div>
<p>Make sure you have installed all the tools mentioned in this chapter, practice using them and try to learn the most common commands and keystrokes. Check out the appropriate <b>man</b> and <b>info</b> pages for more information.</p>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a href="indexs04.html">Prev</a><EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Home</a></td>
<td width="40%" align="right"><EFBFBD><a href="indexs06.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left">Source Tour<75></td>
<td width="20%" align="center"><a href="index.html">Up</a></td>
<td width="40%" align="right"><EFBFBD>Tasks</td>
</tr>
</table>
</div>
</body>
</html>

146
docs/kernelhacking-HOWTO/indexs06.html Normal file
View File

@@ -0,0 +1,146 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<title>Tasks</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.40">
<link rel="home" href="index.html" title="Kernel Hacking HOWTO">
<link rel="up" href="index.html" title="Kernel Hacking HOWTO">
<link rel="previous" href="indexs05.html" title="Tools">
<link rel="next" href="indexs07.html" title="Basic Functions">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Tasks</th></tr>
<tr>
<td width="20%" align="left">
<a href="indexs05.html">Prev</a><EFBFBD></td>
<th width="60%" align="center"><EFBFBD></th>
<td width="20%" align="right"><EFBFBD><a href="indexs07.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="sect1">
<a name="tasks"></a><div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="tasks"></a>Tasks</h2></div></div>
<p>This chapter provides descriptions of some common kernel related tasks.</p>
<div class="sect2">
<a name="generalkernel"></a><div class="titlepage"><div><h3 class="title">
<a name="generalkernel"></a>General Kernel</h3></div></div>
<p>The information in this section is a summary of <a href="http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html" target="_top">the kernel-HOWTO</a>
</p>
<div class="sect3">
<a name="compilekernel"></a><div class="titlepage"><div><h4 class="title">
<a name="compilekernel"></a>Kernel Compilation and Installation</h4></div></div>
<p>This section briefly outlines the procedure for generating a bootable kernel image from source code.</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46573217"></a>Unpack the source code: <b>tar xIvf linux-2.4.16 -C /usr/src</b>.</p></li>
<li><p>
<a name="id46573227"></a><b>make config</b> and answer the list of questions with &quot;y&quot; to build an option into the kernel, &quot;n&quot; to leave it out and &quot;m&quot; to build it as a module. &quot;?&quot; gets you help on most options.</p></li>
<li><p>
<a name="id46573235"></a>Review the <tt>.config</tt> file found in the top level source directory and change as necessary.</p></li>
<li><p>
<a name="id46573244"></a><b>make bzImage modules</b>
</p></li>
<li><p>
<a name="id46573250"></a>Become root and <b>make modules_install</b>
</p></li>
<li><p>
<a name="id46573257"></a>Copy <tt>System.map</tt> to <tt>/boot/System-2.4.14.map</tt>
</p></li>
<li><p>
<a name="id46573268"></a>Copy <tt>~/arch/i386/boot/bzImage</tt> to <tt>/boot/bzImage-2.4.14</tt> (or whatever kernel version you are using).</p></li>
<li><p>
<a name="id46573280"></a>Edit <tt>/etc/lilo.conf</tt> and add a new entry for your new image, using one of the existing ones as a template. Keep at least one of the old entries in case the new kernel does not boot.</p></li>
<li><p>
<a name="id46573290"></a>Run <b>/sbin/lilo</b>, as root.</p></li>
<li><p>
<a name="id46573298"></a>Shutdown and reboot, be sure to select your new kernel at the boot loader prompt, if you did not set it up to boot by default.</p></li>
<li><p>
<a name="id46573303"></a>Enjoy the new kernel!</p></li>
</ul></div>
<p>Note that you can set the default kernel for the next reboot only by re-running lilo with the <b>-R</b> switch followed by the appropriate image label.</p>
</div>
</div>
<div class="sect2">
<a name="generalhacking"></a><div class="titlepage"><div><h3 class="title">
<a name="generalhacking"></a>General Hacking</h3></div></div>
<p>This section is still very incomplete...</p>
<div class="sect3">
<a name="printk"></a><div class="titlepage"><div><h4 class="title">
<a name="printk"></a>Print messages to kernel logs</h4></div></div>
<p>The <tt>printk()</tt> function can be used to output tracing/debugging info to the kernel logs.</p>
</div>
<div class="sect3">
<a name="newmodule"></a><div class="titlepage"><div><h4 class="title">
<a name="newmodule"></a>Creating a new module</h4></div></div>
<p>See forthcoming revised <a href="http://www.dirac.org/linux/writing/" target="_top">Linux Module Programming Guide</a>.</p>
</div>
<div class="sect3">
<a name="configoptions"></a><div class="titlepage"><div><h4 class="title">
<a name="configoptions"></a>Configuration options</h4></div></div>
<p>The easiest way to add boot time options is to find the existing kernel option that matches your requirements most closely and copy that. Take a look at and edit the Config.in file in the associated directory. Then surround your option specific code with inclusion guards.</p>
</div>
<div class="sect3">
<a name="bootparams"></a><div class="titlepage"><div><h4 class="title">
<a name="bootparams"></a>Boot time parameters</h4></div></div>
<p>It is possible to pass information to the kernel at boot time in the form of command line options. For information about the current list of options, see <tt>~/Documentation/kernel-parameters.txt</tt> and the <a href="http://www.linuxdoc.org/HOWTO/BootPrompt-HOWTO.html" target="_top">Linux BootPrompt-HOWTO</a>.</p>
<p>Some drivers make use of this facility to set base addresses where hardware auto-detection is not possible or not implemented. Boot time parameters are especially useful when drivers or features are compiled into the kernel and not as a module, where options can be given when the module is loaded.</p>
<p>At version 2.3.13 the kernel initialisation code changed significantly for the better. Previously, the initialisation code was covered in <tt>#ifdef SOME_CONFIG_OPTION</tt> statements, to ensure only the required initialisation code is compiled into the final image. Now a different approach is taken, known as &quot;init calls&quot;, where the initialisation functions are registered and stored in a special location in the ELF executable format. At system start up, each of the registered functions is called in turn (although it is not possible to specify the order of execution, so some <tt>#ifdef</tt> statements remain).</p>
<p>A similar approach is used to parse boot time options. To associate a particular boot time string with its own handling function, a call is made to <tt>__setup()</tt>. This could be done from <tt>~/init/main.c</tt>.</p>
<p>For example, to add support for a command line option <b>uptime</b>, which sets initial uptime to a specified number of jiffies:</p>
<pre class="programlisting">
static int __init riguptime(char *line){
jiffies = simple_strtol(line, (char **)(line + sizeof(line)), (unsigned int)10);
return 0;
}
__setup(&quot;uptime=&quot;, riguptime);
</pre>
<p>So if the kernel was booted with <b>uptime=12345</b> as a command line option, <tt>*line</tt> (passed to <tt>riguptime()</tt>) would point to a null-terminated string containing &quot;12345&quot;. This string is converted to a value of type long by the <tt>simple_strtol()</tt> macro.</p>
</div>
<div class="sect3">
<a name="syscall"></a><div class="titlepage"><div><h4 class="title">
<a name="syscall"></a>Adding a system call</h4></div></div>
<p>It should be possible to do just about everything you could need to without doing this. Really.</p>
<p>OK so you <i>still</i> want to? (&quot;Don't try this at home kids!&quot;)</p>
<p>See <a href="http://fossil.wpi.edu/docs/howto_add_systemcall.html" target="_top">this tutorial</a> (but needs adapting for 2.4.x).</p>
</div>
<div class="sect3">
<a name="procentry"></a><div class="titlepage"><div><h4 class="title">
<a name="procentry"></a>Add a /proc entry</h4></div></div>
<p>One of the ways to avoid adding another system call is to use the <tt>/proc</tt> interface. This section will describe a simple example.</p>
</div>
</div>
<div class="sect2">
<a name="bughunting"></a><div class="titlepage"><div><h3 class="title">
<a name="bughunting"></a>Bug Hunting</h3></div></div>
<p>The scenario: You have just upgraded to the latest and greatest kernel, only to find it Oopses on your machine. The Linux-Kernel mailing list gets several posts a day along the lines of &quot;2.4.xx&quot; oopses/fails to boot. What is wrong?&quot; Most of these posts never get answered, sometimes even the ones with a little more information (including the dreaded <tt>.config</tt> file) get no response.</p>
<p>Generally, the posts that do get answered and resolved are those where the user has done some &quot;home work&quot; and is some way towards locating the problem.</p>
<p>So where do you start with tracking down the problem?</p>
<p>For now, see <tt>Documentation/BUG-HUNTING</tt> until this section gets finished.</p>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a href="indexs05.html">Prev</a><EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Home</a></td>
<td width="40%" align="right"><EFBFBD><a href="indexs07.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left">Tools<EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Up</a></td>
<td width="40%" align="right"><EFBFBD>Basic Functions</td>
</tr>
</table>
</div>
</body>
</html>

49
docs/kernelhacking-HOWTO/indexs07.html Normal file
View File

@@ -0,0 +1,49 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<title>Basic Functions</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.40">
<link rel="home" href="index.html" title="Kernel Hacking HOWTO">
<link rel="up" href="index.html" title="Kernel Hacking HOWTO">
<link rel="previous" href="indexs06.html" title="Tasks">
<link rel="next" href="indexs08.html" title="Drivers &amp; Modules">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Basic Functions</th></tr>
<tr>
<td width="20%" align="left">
<a href="indexs06.html">Prev</a><EFBFBD></td>
<th width="60%" align="center"><EFBFBD></th>
<td width="20%" align="right"><EFBFBD><a href="indexs08.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="sect1">
<a name="basicfunctions"></a><div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="basicfunctions"></a>Basic Functions</h2></div></div>
<p>There are a core set of kernel functions that every kernel programmer should know about. This chapter will be heavily based on the corresponding chapter from the <a href="http://netfilter.samba.org/unreliable-guides/kernel-hacking/lk-hacking-guide.html" target="_top">original kernelhacking-HOWTO by Rusty Russell</a>.</p>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a href="indexs06.html">Prev</a><EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Home</a></td>
<td width="40%" align="right"><EFBFBD><a href="indexs08.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left">Tasks<EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Up</a></td>
<td width="40%" align="right"><EFBFBD>Drivers &amp; Modules</td>
</tr>
</table>
</div>
</body>
</html>

55
docs/kernelhacking-HOWTO/indexs08.html Normal file
View File

@@ -0,0 +1,55 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<title>Drivers &amp; Modules</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.40">
<link rel="home" href="index.html" title="Kernel Hacking HOWTO">
<link rel="up" href="index.html" title="Kernel Hacking HOWTO">
<link rel="previous" href="indexs07.html" title="Basic Functions">
<link rel="next" href="indexs09.html" title="Kernel Debugging">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Drivers &amp; Modules</th></tr>
<tr>
<td width="20%" align="left">
<a href="indexs07.html">Prev</a><EFBFBD></td>
<th width="60%" align="center"><EFBFBD></th>
<td width="20%" align="right"><EFBFBD><a href="indexs09.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="sect1">
<a name="drivers"></a><div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="drivers"></a>Drivers &amp; Modules</h2></div></div>
<p>This topic is too diverse to be covered in the first version of this document. Please see:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46573578"></a>The O'reilly book entitled &quot;Linux Device Drivers&quot; (2nd Ed.) for a comprehensive guide. You can read it <a href="http://www.xml.com/ldd/chapter/book/index.html" target="_top">online</a>, but buying a hard copy of the book is encouraged.</p></li>
<li><p>
<a name="id46573588"></a><a href="http://www.dirac.org/linux/writing/" target="_top">The Module Programming Guide</a> as a more concentrated source of information. Now maintained by Peter J. Salzman.</p></li>
</ul></div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a href="indexs07.html">Prev</a><EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Home</a></td>
<td width="40%" align="right"><EFBFBD><a href="indexs09.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left">Basic Functions<6E></td>
<td width="20%" align="center"><a href="index.html">Up</a></td>
<td width="40%" align="right"><EFBFBD>Kernel Debugging</td>
</tr>
</table>
</div>
</body>
</html>

488
docs/kernelhacking-HOWTO/indexs09.html Normal file
View File

@@ -0,0 +1,488 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<title>Kernel Debugging</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.40">
<link rel="home" href="index.html" title="Kernel Hacking HOWTO">
<link rel="up" href="index.html" title="Kernel Hacking HOWTO">
<link rel="previous" href="indexs08.html" title="Drivers &amp; Modules">
<link rel="next" href="indexs10.html" title="Profiling &amp; Benchmarking">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Kernel Debugging</th></tr>
<tr>
<td width="20%" align="left">
<a href="indexs08.html">Prev</a><EFBFBD></td>
<th width="60%" align="center"><EFBFBD></th>
<td width="20%" align="right"><EFBFBD><a href="indexs10.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="sect1">
<a name="kerneldebugging"></a><div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="kerneldebugging"></a>Kernel Debugging</h2></div></div>
<div class="sect2">
<a name="whenthingsgowrong"></a><div class="titlepage"><div><h3 class="title">
<a name="whenthingsgowrong"></a>When things go wrong</h3></div></div>
<p>The Linux kernel is not perfect, but it is getting better all the time. Occasionally bugs even creep into the stable kernel series as &quot;improvements&quot; are made. What course of action is appropriate if a problem is discovered? If you are using an unmodified kernel, try going down this checklist before posting a bug report to the kernel mailing list:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46573626"></a>Is the problem reproducible in the latest stable kernel?</p></li>
<li><p>
<a name="id46573631"></a>Has the problem always existed? If so, report it as a bug in the latest kernel. If not, test successive kernels until you have found the version that introduces the problem.</p></li>
<li><p>
<a name="id46573637"></a>Search the kernel mailing list archives for similar reports. If any come to light, try to concentrate your efforts on providing additional information to that already supplied.</p></li>
<li><p>
<a name="id46573643"></a>Check the changelog for clues. If anything in the changelog looks suspicious, examine the patch for that kernel version and find out what relevant code changes occur in that version.</p></li>
</ul></div>
<p>Some (but not all) problems give rise to a screen dump of cryptic debugging information, also known as an &quot;oops&quot;.</p>
</div>
<div class="sect2">
<a name="oopsanalysis"></a><div class="titlepage"><div><h3 class="title">
<a name="oopsanalysis"></a>Oops Analysis</h3></div></div>
<div class="sect3">
<a name="whatisanoops"></a><div class="titlepage"><div><h4 class="title">
<a name="whatisanoops"></a>What is an oops?</h4></div></div>
<p>When the kernel detects that a serious anomalous condition exists, an &quot;oops&quot; is triggered. An oops has two main functions:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46573674"></a>To dump useful debugging information that can be used to diagnose the cause of problem.</p></li>
<li><p>
<a name="id46573679"></a>To try and prevent the kernel from going out of control and causing data corruption, or worse, damage to hardware (although this is very rare).</p></li>
</ul></div>
<p>To the uninitiated, an oops appears completely incomprehensible; a lines of hex values and seemingly cryptic, even amusing error messages:</p>
<pre class="screen">![CDATA[
CPU: 0
EIP: 0010:<font color="red">&lt;c011933c&gt; Tainted: P
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010002
eax: 00000ce0 ebx: 00001000 ecx: c778a510 edx: 00000610
esi: 00000002 edi: 00000000 ebp: c02165c0 esp: c6663f58
ds: 0018 es: 0018 ss: 0018
Process pcmcia (pid: 1003, stackpage=c6663000)
Stack: 00000000 c02165a0 00000000 c02165c0 c6663fc4 c01193cf c010ac96 c0116406
c0116340 00000000 00000001 c02165c0 fffffffe c011616a c02165c0 00000000
c0214900 00000000 c6663fbc 00000046 c010817d 00000000 080caa18 00000000
Call Trace: <font color="red">&lt;c01193cf&gt;<font color="red">&lt;c010ac96&gt;<font color="red">&lt;c0116406&gt;<font color="red">&lt;c0116340&gt;<font color="red">&lt;c011616a&gt;<font color="red">&lt;c010817d&gt;<font color="red">&lt;c0109f48&gt;
Code: 89 42 04 89 10 c7 41 04 00 00 00 00 c7 01 00 00 00 00 fb 53
&gt; &gt; EIP; c011933c <font color="red">&lt;timer_bh&gt;&lt;/timer_bh&gt;</font>+228/27c&gt; =====
Trace; c01193cf <font color="red">&lt;do_timer&gt;&lt;/do_timer&gt;</font>+3f/70&gt;
Trace; c010ac96 <font color="red">&lt;timer_interrupt&gt;&lt;/timer_interrupt&gt;</font>+62/110&gt;
Trace; c0116406 <font color="red">&lt;bh_action&gt;&lt;/bh_action&gt;</font>+1a/48&gt;
Trace; c0116340 <font color="red">&lt;tasklet_hi_action&gt;&lt;/tasklet_hi_action&gt;</font>+40/60&gt;
Trace; c011616a <font color="red">&lt;do_softirq&gt;&lt;/do_softirq&gt;</font>+5a/ac&gt;
Trace; c010817d <font color="red">&lt;do_irq&gt;&lt;/do_irq&gt;</font>+a1/b4&gt;
Trace; c0109f48 <font color="red">&lt;call_do_irq&gt;&lt;/call_do_irq&gt;</font>+5/d&gt;
Code; c011933c <font color="red">&lt;timer_bh&gt;&lt;/timer_bh&gt;</font>+228/27c&gt;
00000000 <font color="red">&lt;_eip&gt;:
Code; c011933c <font color="red">&lt;timer_bh&gt;&lt;/timer_bh&gt;</font>+228/27c&gt; =====
0: 89 42 04 mov %eax,0x4(%edx) =====
Code; c011933f <font color="red">&lt;timer_bh&gt;&lt;/timer_bh&gt;</font>+22b/27c&gt;
3: 89 10 mov %edx,(%eax)
Code; c0119341 <font color="red">&lt;timer_bh&gt;&lt;/timer_bh&gt;</font>+22d/27c&gt;
5: c7 41 04 00 00 00 00 movl $0x0,0x4(%ecx)
Code; c0119348 <font color="red">&lt;timer_bh&gt;&lt;/timer_bh&gt;</font>+234/27c&gt;
c: c7 01 00 00 00 00 movl $0x0,(%ecx)
Code; c011934e <font color="red">&lt;timer_bh&gt;&lt;/timer_bh&gt;</font>+23a/27c&gt;
12: fb sti
Code; c011934f <font color="red">&lt;timer_bh&gt;&lt;/timer_bh&gt;</font>+23b/27c&gt;
13: 53 push %ebx
0&gt;Kernel panic: Aiee, killing interrupt handler!
3 warnings issued. Results may not be reliable.
]]&gt;
&lt;/_eip&gt;</font>&lt;/c0109f48&gt;</font>&lt;/c010817d&gt;</font>&lt;/c011616a&gt;</font>&lt;/c0116340&gt;</font>&lt;/c0116406&gt;</font>&lt;/c010ac96&gt;</font>&lt;/c01193cf&gt;</font>&lt;/c011933c&gt;</font></pre>
</div>
<div class="sect3">
<a name="anatomyofanoops"></a><div class="titlepage"><div><h4 class="title">
<a name="anatomyofanoops"></a>Anatomy of an oops</h4></div></div>
<p>TODO.</p>
</div>
<div class="sect3">
<a name="decodinganoops"></a><div class="titlepage"><div><h4 class="title">
<a name="decodinganoops"></a>Decoding an oops</h4></div></div>
<p>The information provided by an oops is in a very &quot;raw&quot; form, some of which is specific to the kernel image that generated it. Therefore, some post-processing needs to be carried to obtain useful information on where to start with the debugging process. This section will contain a step by step to decoding an oops. A good place to start is <a href="http://www.urbanmyth.org/linux/oops/" target="_top">OOPS! An Introduction to Linux Kernel Debugging.</a>
</p>
</div>
</div>
<div class="sect2">
<a name="usingadebugger"></a><div class="titlepage"><div><h3 class="title">
<a name="usingadebugger"></a>Using a Debugger</h3></div></div>
<div class="sect3">
<a name="aboutdebuggers"></a><div class="titlepage"><div><h4 class="title">
<a name="aboutdebuggers"></a>A Word about debuggers</h4></div></div>
<p>Use of a debugger is generally looked down on by the likes of Linus. Consider these quotes of his from the Linux kernel mailing list:</p>
<table border="0" width="100%" cellspacing="0" cellpadding="0" class="blockquote" summary="Block quote">
<tr>
<td width="10%" valign="top"><EFBFBD></td>
<td width="80%" valign="top"><p>'Use the Source, Luke, use the Source. Be one with the code.'. Think of Luke Skywalker discarding the automatic firing system
when closing on the deathstar, and firing the proton torpedo (or whatever) manually. _Then_ do you have the right mindset for fixing kernel bugs.</p></td>
<td width="10%" valign="top"><EFBFBD></td>
</tr>
<tr>
<td colspan="2" align="right" valign="top">--<span class="attribution">Linus</span>
</td>
<td width="10%" valign="top"><EFBFBD></td>
</tr>
</table>
<p>Also:</p>
<table border="0" width="100%" cellspacing="0" cellpadding="0" class="blockquote" summary="Block quote">
<tr>
<td width="10%" valign="top"><EFBFBD></td>
<td width="80%" valign="top"><p>I'm afraid that I've seen too many people fix bugs by looking at debugger output, and that almost inevitably leads to fixing the symptoms rather than the underlying problems.</p></td>
<td width="10%" valign="top"><EFBFBD></td>
</tr>
<tr>
<td colspan="2" align="right" valign="top">--<span class="attribution">Linus</span>
</td>
<td width="10%" valign="top"><EFBFBD></td>
</tr>
</table>
<p>So are there any good reasons why you should use a debugger? Stop for a moment and consider how the top kernel programmers go about locating and fixing a problem; how do they do it? The answer is that they have many years of programming experience to bring to bare on the situation; chances are they have seen something like this before. They have those &quot;hunches&quot; that semi-automatically lead them to the right place; to the real root of the problem.</p>
<p>So how does the &quot;up and coming&quot; kernel hacker nurture skills like these to maturity, especially when time pressure demands a quick solution? The answer comes in the form of intelligent use of a debugger.</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46573851"></a>Use the debugger to collect the evidence surrounding the problem area(s).</p></li>
<li><p>
<a name="id46573858"></a>Study the code and think about what is going on. hard.</p></li>
<li><p>
<a name="id46573863"></a>Try to concentrate on thinking about possible causes of the symptoms you are seeing in the debugger. Then think about the causes of the causes all the way down to the real root of the problem. Write a list of the possibilities, placing them in order of perceived likelihood and rule them out in turn, one by one. The process of clarifying thoughts to write them down can be valuable.</p></li>
<li><p>
<a name="id46573873"></a>Until you have some experience, you may need to use the debugger to try some ideas out on the fly by changing variable values etc.</p></li>
</ul></div>
<p>Note that we are using the debugger here as a tool to stimulate rational, logical thought on what is going on in the code. As you get more experienced at tracking bugs down, you will be able to use the debugger less; you won't need as many clues before you see the problem. If you use the debugger wisely, you'll gain the expertise of the &quot;hardcore&quot; kernel hackers, but in less time.</p>
<p>In summary, some do's and don'ts:</p>
<p>Do:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46570252"></a>Study the code before you set to with the debugger; you will be more productive if you have thought about the code first.</p></li>
<li><p>
<a name="id46570259"></a>Use the debugger to test your assumptions; bugs often come about as a result of incorrect assumptions (have you ever seen those &quot;we should never get here&quot; debugging messages?).</p></li>
<li><p>
<a name="id46570267"></a>If your assumptions are proved wrong, make it your business to get to the bottom of why you got it wrong and make a mental note for next time.</p></li>
<li><p>
<a name="id46570274"></a>Discard the debugger as soon as possible; think of Luke Skywalker again here!</p></li>
</ul></div>
<p>Don't:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46570284"></a>Ignore the real cause of problems that come to light. When you find something amiss, don't just shrug your shoulders and fix things up so that everything looks OK. A classic example is adding another section to a switch statement to cover an eventuality you hadn't thought of. Do you understand why that scenario is occurring? Consider the possibility that your approach and/or assumptions are flawed. Don't go &quot;wall-papering over the cracks&quot;; you'll only have to fix it properly later on (or worse, someone else will).</p></li>
<li><p>
<a name="id46570295"></a>Blindly use the debugger to narrow a problem down; you could well come to the wrong conclusion and you won't learn as much in the process.</p></li>
</ul></div>
<p>Now that we have some idea of what debuggers are good for (and not so good for), some of the options available to you will be presented in the next section.</p>
</div>
<div class="sect3">
<a name="debuggingtechniques"></a><div class="titlepage"><div><h4 class="title">
<a name="debuggingtechniques"></a>Debugging Techniques</h4></div></div>
<p>There are four different approaches to kernel debugging (apart from the <tt>printk()</tt> method which doesn't really count):</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46574039"></a>Local kernel debugging (done by running gdb with <tt>/proc/kcore</tt> as the core file), this approach is of very limited use; amongst other limitations, no breakpoints can be set.</p></li>
<li><p>
<a name="id46574050"></a>User Mode Linux; a way to run Linux inside Linux. This is good for general hacking as no extra hardware is required but not so good for troubleshooting a hardware specific problem. For more information on User Mode Linux, see: <a href="http://user-mode-linux.sourceforge.net" target="_top">the User Mode Linux Homepage</a>
</p></li>
<li><p>
<a name="id46574056"></a>Local kernel debugging using kdb.</p></li>
<li><p>
<a name="id46574062"></a>Remote kernel debugging using gdb. Here the kernel under test runs on a physically separate machine and communicates with the controlling machine running the debugger, via a serial link. This is the approach described in this document.</p></li>
</ul></div>
<p>If you have never used the gdb debugger, I strongly suggest you familiarise yourself with it in userspace before delving into kernel debugging. This <a href="http://www.refcards.net/about/gdb.html" target="_top">gdb reference card</a> is very useful. While there are some graphical front ends for gdb (including xxgdb and ddd), it is a good idea to get used to using plain gdb on the console; it is better not to be running X while kernel hacking/debugging; you may miss crucial console output or worse, an oops. Kernel compiles can also be faster on a machine without X running, especially on machines with less than 64MB RAM, as X uses a significant amount of RAM.</p>
</div>
<div class="sect3">
<a name="hardwaresetup"></a><div class="titlepage"><div><h4 class="title">
<a name="hardwaresetup"></a>Hardware Setup</h4></div></div>
<p>The two machines in this example will be referred to as &quot;kernighan&quot; (workstation/development machine) and ``ritchie'' (testing machine that actually runs the development kernels).</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46574112"></a>First of all, you need a machine to be your testing box. Note that it does not have to have a monitor, keyboard and mouse. My testing machine was cobbled together from spare parts! A keyboard can be useful though, in order to be able to use the magic SysRq key.</p></li>
<li><p>
<a name="id46574117"></a>Set up ethernet between the two machines. Check you can ping &quot;ritchie&quot; by using it's hostname.</p></li>
<li>
<p>
<a name="id46574122"></a>Build two serial cables using the pin out given below. One cable will be used by gdb, the other will be used to give access to the console of testing. This saves having another monitor on the desk and makes capturing Oopsen a lot easier. The ethernet connection is useful for multiple remote logins and quickly transferring kernel images etc. Here is the serial cable pin out: Din 9 pin to Din 9 pin:</p>
<pre class="screen">![CDATA[
Solder-side pins:
\-----------------------/
\ 1 2 3 4 5 /
\ 6 7 8 9 /
\-----------------/
Wiring: (use 7 or 10 wire foil screened cable)
1
|
6---------------4
2---------------3
3---------------2
4---------------6
|
1
5---------------5
7---------------8
8---------------7
]]&gt;
</pre>
<p>Connect the cable screen to the chassis of one of the connectors, this will help prevent an earth loop between the two machines. This pin out was taken from the text-terminal-howto, I decided to reproduce it here to remove the confusion over which of the many pin outs to use. a standard null-modem cable may work if you don't want to build the cable(s) yourself, however i had to modify mine to the above configuration to make it work. If you go out and buy a null-modem cable especially, I'd advise getting one with connectors that can be disassembled (i.e. not moulded on connectors) to make modification possible.</p>
<p>If you have a Radio Shack store nearby, here are some part numbers:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46574154"></a>Serial cable: 26-152B (Female DB9 - Female DB9)</p></li>
<li><p>
<a name="id46574160"></a>Null Modem adapter: 26-264B (Female DB9 - Male DB9)</p></li>
</ul></div>
<p>Thanks to Pragnesh Sampat for providing this information.</p>
</li>
<li><p>
<a name="id46574167"></a>connect the two machines together using the two serial cables, com1 to com1, com2 to com2.</p></li>
</ul></div>
</div>
<div class="sect3">
<a name="softwaresetup"></a><div class="titlepage"><div><h4 class="title">
<a name="softwaresetup"></a>Software Setup</h4></div></div>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46574176"></a>Install ssh on &quot;kernighan&quot;.</p></li>
<li><p>
<a name="id46574189"></a>Install sshd on &quot;ritchie&quot; (this is part of the ssh package for some distributions, including Debian).</p></li>
<li><p>
<a name="id46574202"></a>Check you can log in via ssh to &quot;ritchie&quot; (note: you won't be able to log in as root, but you can su to root once logged in as a user, should you need to).</p></li>
<li><p>
<a name="id46574216"></a>Give yourself read/write access to <tt>dev/ttyS0</tt> and <tt>/dev/ttyS1</tt> on both machines.</p></li>
<li><p>
<a name="id46574228"></a>Install minicom on both machines.</p></li>
</ul></div>
</div>
<div class="sect3">
<a name="compilation"></a><div class="titlepage"><div><h4 class="title">
<a name="compilation"></a>Compilation</h4></div></div>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46574242"></a>Download and unpack the kernel source to your home directory on &quot;kernighan&quot;.</p></li>
<li><p>
<a name="id46574251"></a>Download the kgdb patch, to the top level kernel source directory from <a href="http://kgdb.sourceforge.net/downloads.html" target="_top">the kgdb home page</a>
</p></li>
<li><p>
<a name="id46574261"></a>Apply the patch: <b>bash-2.03\$ cat kgdb\_2.2.18.diff |patch -p2</b>
</p></li>
<li><p>
<a name="id46574266"></a><b>make menuconfig</b> (or copy your standard <tt>.config</tt> file and <tt>make oldconfig</tt>).</p></li>
<li>
<p>
<a name="id46574289"></a>Select the usual configuration options, adding:</p>
<pre class="screen">
o support for console on serial port under character devices
o kernel support for gdb (new) under kernel hacking.
</pre>
<p>I would advise compiling all additional options directly into the kernel, rather than as modules to start with.</p>
</li>
<li><p>
<a name="id46574300"></a>If you have a keyboard directly attached to your testing machine, you may also want to add magic sysrq key support, be sure to read (and maybe print out) <tt>Documentation/sysrq.txt</tt>.</p></li>
<li><p>
<a name="id46574310"></a>Proceed with a normal compilation: <b>make dep bzImage</b>.</p></li>
<li><p>
<a name="id46574319"></a>Copy the image over to &quot;ritchie&quot;: <b>scp arch/i386/boot/bzImage ritchie:bzimage-2.2.18-kgdb</b> (note: you will need to have the same user name on ``kernighan'' and ``ritchie'' for this command to work). Alternatively you could setup and use FTP (less secure).</p></li>
<li><p>
<a name="id46574333"></a><b>ssh</b> into &quot;ritchie&quot;, become root and move the image into <tt>/boot</tt>.</p></li>
<li>
<p>
<a name="id46574344"></a>create a new entry in <tt>/etc/lilo.conf</tt> (on &quot;ritchie&quot;):</p>
<pre class="screen">![CDATA[
image=/boot/bzImage-2.2.18-kgdb
label=kgdb
root=/dev/hda1
read-only
append=&quot; gdb gdbttys=0 console=ttys1&quot;
]]&gt;
</pre>
<p>The extra command line options tell the gdb debugging stub to listen on <tt>/dev/ttyS0</tt>, and to tell the kernel to use <tt>/dev/ttyS1</tt> as a serial console. You can also control lilo (i.e. choose which image to boot) from the serial console if you add:</p>
<pre class="screen">
serial = 0,9600n8
</pre>
<p>to the top of your lilo configuration file.</p>
</li>
<li><p>
<a name="id46574383"></a>Run lilo (on testing).</p></li>
<li><p>
<a name="id46574392"></a>If you decided not to make the debugging kernel the default kernel, run <b>lilo -R kgdb</b> to make the new image boot following the next reboot only. (That way if the debugging kernel fails to boot for whatever reason, the machine will boot a working kernel next time to enable you to resolve the problem).</p></li>
<li>
<p>
<a name="id46574403"></a>Create a file named <tt>.gdbinit</tt> in the top level directory of the kernel source tree on &quot;kernighan&quot;, containing the following:</p>
<pre class="screen">
define rmt
set remotebaud 38400
target remote /dev/ttyS0
end
</pre>
</li>
<li>
<p>
<a name="id46574415"></a>Run (as root) minicom -s on &quot;kernighan&quot;, go to serial port setup and select these options:</p>
<pre class="screen">![CDATA[
Serial Device : /dev/ttyS1
Lockfile Location : /var/lock
Callin Program :
Callout Program :
Bps/Par/Bits : 9600 8N1
Hardware Flow Control : No
Software Flow Control : No
]]&gt;
</pre>
</li>
<li><p>
<a name="id46574428"></a>Go to &quot;Save setup as dfl&quot;, and save settings as default before going to Exit, leaving minicom awaiting input.</p></li>
</ul></div>
</div>
</div>
<div class="sect2">
<a name="debugsession"></a><div class="titlepage"><div><h3 class="title">
<a name="debugsession"></a>The Debugging Session</h3></div></div>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46574438"></a>Shutdown and reboot &quot;ritchie&quot;.</p></li>
<li>
<p>
<a name="id46574447"></a>After the BIOS Power On Self Test the debug kernel should load on testing, giving the following output in minicom on &quot;kernighan&quot;:</p>
<pre class="screen">![CDATA[
Linux version 2.2.18serialgdb (jfreak@kernighan) (gcc version 2.95.2 20000220 (Debian GNU/Linux)) #6 Fri Jun 15 17:02:55 BST 2001
Detected 167046 kHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 333.41 BogoMIPS
Memory: 63556k/65536k available (704k kernel code, 408k reserved, 824k data, 44k init)
Dentry hash table entries: 8192 (order 4, 64k)
Buffer cache hash table entries: 65536 (order 6, 256k)
Page cache hash table entries: 16384 (order 4, 64k)
CPU: Intel Pentium 75 - 200 stepping 0c
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' instruction... OK.
Intel Pentium with F0 0F bug - workaround enabled.
POSIX conformance testing by UNIFIX
Trying to free free IRQ4
Waitng for connection from remote gdb on ttyS0
]]&gt;
</pre>
</li>
<li><p>
<a name="id46574462"></a>On &quot;kernighan&quot;, type <b>gdb vmlinux</b>&gt; (in the top level kernel source directory). gdb will start and you should see a license notice followed by a (gdb) prompt.</p></li>
<li>
<p>
<a name="id46574480"></a>Type <b>rmt</b> at the gdb prompt (and press enter). This reads the rmt command from your <tt>.gdbinit</tt> file. If the serial link is working correctly, gdb should give the following output:</p>
<pre class="screen">![CDATA[
(gdb) rmt
0xc010da29 in breakpoint () at gdb.c:701
701 if (initialized) BREAKPOINT();
(gdb)
]]&gt;
</pre>
<p>Note: the hex address will be different for each kernel image. At this point, gdb is paused awaiting user input. You may set breakpoints, watch expressions etc. here before giving the continue command <b>c</b>.</p>
</li>
<li><p>
<a name="id46574518"></a>The debug kernel will continue to boot (giving further output in minicom on &quot;kernighan&quot;).</p></li>
<li><p>
<a name="id46574527"></a>Once booting is finished, check that you can ssh into &quot;ritchie&quot;.</p></li>
<li><p>
<a name="id46574531"></a>You may then set up a test case to cause the debug kernel to run the code to be debugged.</p></li>
<li><p>
<a name="id46574536"></a>You may add breakpoints by using Ctrl-C to get a gdb prompt.</p></li>
</ul></div>
</div>
<div class="sect2">
<a name="troubleshooting"></a><div class="titlepage"><div><h3 class="title">
<a name="troubleshooting"></a>Troubleshooting</h3></div></div>
<p>If the serial link does not appear to be working, try going down this check list:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46574562"></a>Check that the serial cables are connected to the right ports.</p></li>
<li><p>
<a name="id46574570"></a>Check the serial ports have correct baud rate, parity settings etc.</p></li>
<li><p>
<a name="id46574575"></a>Double check cable wiring against pin out diagram.</p></li>
<li><p>
<a name="id46574580"></a>If possible, check the continuity of the serial cable with a multi-meter or continuity tester.</p></li>
<li><p>
<a name="id46574584"></a>ssh into &quot;ritchie&quot; and set up a minicom to minicom session between the two machines. Typing in one minicom session should produce output on the other.</p></li>
</ul></div>
<p>If you have a Palm Pilot, it can be used as a serial console in conjunction with the cradle (a very useful tool for trouble shooting). You'll need a copy of ptelnet, available from <a href="http://netpage.em.com.br/mmand/ptelnet.htm" target="_top">the ptelnet home page</a>. Use the following options in Options-&gt;Terminal:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46574626"></a>Mode: Serial</p></li>
<li><p>
<a name="id46574630"></a>Return: CR</p></li>
</ul></div>
<p>And in Options-&gt;Serial:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46574646"></a>Baud: 9600</p></li>
<li><p>
<a name="id46574651"></a>Parity: N</p></li>
<li><p>
<a name="id46574655"></a>Word: 8</p></li>
<li><p>
<a name="id46574659"></a>StopBits: 1</p></li>
<li><p>
<a name="id46574663"></a>Xon/Xoff: not checked</p></li>
<li><p>
<a name="id46574667"></a>RTS/CRS: not checked</p></li>
</ul></div>
<p>If you are unable to <b>ssh</b> into &quot;ritchie&quot; when running the debug kernel, check the following:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46574680"></a>You compiled in support for your ethernet card (not as a module!).</p></li>
<li><p>
<a name="id46574685"></a>You compiled in sufficient network support to enable ethernet use.</p></li>
<li><p>
<a name="id46574690"></a>Make sure you aren't root (or use <b>ssh -l username</b> to stop ssh from trying to log in as root).</p></li>
</ul></div>
</div>
<div class="sect2">
<a name="miscnotes"></a><div class="titlepage"><div><h3 class="title">
<a name="miscnotes"></a>Misc. Notes</h3></div></div>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46574704"></a>The gdb interface defaults to 38400bps, this can be increased right up to 115200bps which may speed up debugging sessions, at the expense of stability.</p></li>
<li><p>
<a name="id46574719"></a>The serial console defaults to 9600bps, this too can be increased up to 115200bps which is useful if you want to run curses based programs on the console, as redraws are painfully slow at 9600bps!</p></li>
</ul></div>
</div>
<div class="sect2">
<a name="usingthelogs"></a><div class="titlepage"><div><h3 class="title">
<a name="usingthelogs"></a>Using the logs</h3></div></div>
<p>Of course, it is possible debug the kernel without a debugger, simply by printing out lots of tracing to the log files and carrying out a post-mortem afterwards. One problem with this approach is that if your code is called a lot, you can end up flooding the log files to the extent that the machine becomes unusable and/or you fill your disk up! One way to avoid this problem is to put your printk statements inside conditional code that is only executed by a &quot;special&quot; user (e.g. a user with a UID of 9999), then call/exercise that code as that special user:</p>
<pre class="screen">
... if (current-&gt;uid == 9999)
printk(&quot;your debug info&quot;);
...
</pre>
<p>Like most techniques, this one is good in some situations and not so good in others; try it out and find how/when it works best for you. Many thanks to Andrew Morton for posting this tip to the Linux Kernel Mailing list.</p>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a href="indexs08.html">Prev</a><EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Home</a></td>
<td width="40%" align="right"><EFBFBD><a href="indexs10.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left">Drivers &amp; Modules<65></td>
<td width="20%" align="center"><a href="index.html">Up</a></td>
<td width="40%" align="right"><EFBFBD>Profiling &amp; Benchmarking</td>
</tr>
</table>
</div>
</body>
</html>

100
docs/kernelhacking-HOWTO/indexs10.html Normal file
View File

@@ -0,0 +1,100 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<title>Profiling &amp; Benchmarking</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.40">
<link rel="home" href="index.html" title="Kernel Hacking HOWTO">
<link rel="up" href="index.html" title="Kernel Hacking HOWTO">
<link rel="previous" href="indexs09.html" title="Kernel Debugging">
<link rel="next" href="indexs11.html" title="The Linux Kernel Development Cycle">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Profiling &amp; Benchmarking</th></tr>
<tr>
<td width="20%" align="left">
<a href="indexs09.html">Prev</a><EFBFBD></td>
<th width="60%" align="center"><EFBFBD></th>
<td width="20%" align="right"><EFBFBD><a href="indexs11.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="sect1">
<a name="profiling"></a><div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="profiling"></a>Profiling &amp; Benchmarking</h2></div></div>
<div class="sect2">
<a name="whyprofile"></a><div class="titlepage"><div><h3 class="title">
<a name="whyprofile"></a>Why profile?</h3></div></div>
<p>Naturally, you should aim for efficiency by design and by writing tight code. Profiling is done to locate sections of code that are called most often and/or consume the most CPU time. Optimisation effort can then be focused on those routines, giving the best return on the time invested. If you have never profiled code before, it would be an idea to get acquainted with gprof, a typical userspace command line profiler.</p>
<p>Just as it is poor practice to rely on a debugger to catch bad code, so it is bad practice to rely on a profiler to catch inefficient code.</p>
</div>
<div class="sect2">
<a name="basicprofiling"></a><div class="titlepage"><div><h3 class="title">
<a name="basicprofiling"></a>Basic profiling</h3></div></div>
<p>The kernel has some built in profiling functionality. If you add profile=1 to your kernel command line arguments, then you get a file: <tt>proc/profile</tt> which can be used by readprofile to print profiling information to standard output. Example output from readprofile:</p>
<pre class="screen">
$readprofile
2 stext 0.0500
514867 default_idle 12871.6750
1 copy_thread 0.0071
1 restore_sigcontext 0.0030
2 system_call 0.0312
2 handle_IRQ_event 0.0227
13 do_page_fault 0.0111
1 schedule 0.0012
1 wake_up_process 0.0132
1 copy_mm 0.0014
-------8---Snip---8-----------------
</pre>
<p>The first column contains the number of clock ticks spent in a function (second column), while the third column gives the normalised load; the number of clock ticks divided by the length of the function.</p>
<p>See <b>man readprofile</b> for details and useful examples. readprofile is usually part of the <tt>util-linux</tt> package. Sometimes readprofile is kept in <tt>/usr/sbin</tt>, so you may need to add that directory to your <b>PATH</b> or soft link it to some directory that is in your path, e.g. <tt>/usr/bin</tt>.</p>
<p>Note that if you want to carry out profiling on a remote machine, you will need to copy <tt>System.map</tt> and <tt>vmlinux</tt> across to <tt>/usr/src/linux</tt> from the top level source directory where the running kernel was compiled.</p>
<p>For more information on benchmarking, see the <a href="http://www.linuxdoc.org/HOWTO/Benchmarking-HOWTO.html" target="_top">benchmarking-HOWTO</a>
</p>
<div class="sect2">
<a name="profiletask"></a><div class="titlepage"><div><h3 class="title">
<a name="profiletask"></a>Your turn</h3></div></div>
<p>Using the information in this chapter, profile your system carrying out an intensive task such as:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46574887"></a>Running <b>find</b> on the root directory to locate a particular file. Compare with running <b>updatedb</b> followed by <b>locate</b>
</p></li>
<li><p>
<a name="id46574903"></a>Opening multiple heavy weight apps e.g. <b>mozilla</b>, <b>OpenOffice</b>, <b>nautilus</b>, use top to make sure you have driven your system into swapping out to disk.</p></li>
<li><p>
<a name="id46574921"></a>Playing a high resolution mpeg video using your favourite media player.</p></li>
<li><p>
<a name="id46574925"></a>Compiling a small application</p></li>
<li><p>
<a name="id46574929"></a>Compiling a kernel</p></li>
<li><p>
<a name="id46574933"></a>If possible try and simulate a heavy network load.</p></li>
</ul></div>
<p>The idea here is to get an understanding of the places that the kernel spends most of its time during everyday operations.</p>
<p>Now using <b>lxr</b> (or some other source code navigation tool), locate the most referenced functions, get familiar with them and try and understand what each function does.</p>
</div>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a href="indexs09.html">Prev</a><EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Home</a></td>
<td width="40%" align="right"><EFBFBD><a href="indexs11.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left">Kernel Debugging<6E></td>
<td width="20%" align="center"><a href="index.html">Up</a></td>
<td width="40%" align="right"><EFBFBD>The Linux Kernel Development Cycle</td>
</tr>
</table>
</div>
</body>
</html>

91
docs/kernelhacking-HOWTO/indexs11.html Normal file
View File

@@ -0,0 +1,91 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<title>The Linux Kernel Development Cycle</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.40">
<link rel="home" href="index.html" title="Kernel Hacking HOWTO">
<link rel="up" href="index.html" title="Kernel Hacking HOWTO">
<link rel="previous" href="indexs10.html" title="Profiling &amp; Benchmarking">
<link rel="next" href="indexs12.html" title="Tips">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">The Linux Kernel Development Cycle</th></tr>
<tr>
<td width="20%" align="left">
<a href="indexs10.html">Prev</a><EFBFBD></td>
<th width="60%" align="center"><EFBFBD></th>
<td width="20%" align="right"><EFBFBD><a href="indexs12.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="sect1">
<a name="develcycle"></a><div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="develcycle"></a>The Linux Kernel Development Cycle</h2></div></div>
<p>Before actively contributing to kernel development, it is important to understand the development cycle adopted by the Linux kernel community. This chapter describes the development process.</p>
<div class="sect2">
<a name="stableseries"></a><div class="titlepage"><div><h3 class="title">
<a name="stableseries"></a>Stable Series</h3></div></div>
<p>The stable series have even point release numbers (e.g. 2.2.x and 2.4.x.), generally minor releases contain bug fixes and small enhancements. Stable releases generally occur less often and most Linux distributions are based around these releases. Some &quot;vintages&quot; of kernel are better than others, the really bad ones are marked with a &quot;-dontuse&quot; filename extension.</p>
</div>
<div class="sect2">
<a name="unstableseries"></a><div class="titlepage"><div><h3 class="title">
<a name="unstableseries"></a>Unstable Series</h3></div></div>
<p>Unstable kernels contain less proven code and change more radically between minor releases. They serve as test beds for new drivers, experimental features and innovative algorithms.</p>
<p>Generally, it is a bad idea to run an unstable kernel on a system that matters. Having a dedicated box for testing unstable kernels is recommended!</p>
</div>
<div class="sect2">
<a name="featurefreezes"></a><div class="titlepage"><div><h3 class="title">
<a name="featurefreezes"></a>Feature Freezes</h3></div></div>
<p>Linus announces a feature freeze to indicate that he will not be considering any more new features until the release of a new stable kernel. This is usually followed by a flurry of people trying to get patches into the source tree before Linus actually enforces the feature freeze!</p>
<p>The idea is to introduce a period of stability to hunt down and fix the worst of the bugs introduced by all the new features.</p>
</div>
<div class="sect2">
<a name="codefreezes"></a><div class="titlepage"><div><h3 class="title">
<a name="codefreezes"></a>Code Freezes</h3></div></div>
<p>Code freezes are similar in concept to feature freezes, but are more restrictive; only fixes for serious bugs are accepted. Code freezes are just one more step towards the release of a new stable kernel.</p>
</div>
<div class="sect2">
<a name="intermediatepatches"></a><div class="titlepage"><div><h3 class="title">
<a name="intermediatepatches"></a>Intermediate Patches</h3></div></div>
<p>Between minor releases of both stable and unstable kernels, there are several intermediate releases intended to iteratively test a small number of submissions together. These releases have either -preXX or -YYXX extensions, where XX is the incremental version number and YY are the initials of the maintainer (example: -ac12 indicates the 12th incremental release by Alan Cox).</p>
</div>
<div class="sect2">
<a name="devyourturn"></a><div class="titlepage"><div><h3 class="title">
<a name="devyourturn"></a>Your Turn</h3></div></div>
<p>Now head over to the Linux-Kernel mailing list archives and spend some time looking over the postings of the past month or so. Try and find/follow a couple of threads that look interesting to you, where the maintainers get involved. If you don't know who is who in the community, take a look at the MAINTAINERS file in the top level of the kernel source tree.</p>
<p>By doing this you will:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46575055"></a>Gain a practical understanding of the day to day development process.</p></li>
<li><p>
<a name="id46575061"></a>Find out who knows what they are talking about (and who doesn't!).</p></li>
<li><p>
<a name="id46575065"></a>Discover what the current issues are and who is working on them.</p></li>
</ul></div>
<p>Now find and try out some experimental patches that look interesting to you and provide feedback to the author. If you think it is appropriate to post back to the list, be sure to read <a href="http://www.tux.org/lkml/" target="_top">the FAQ</a><i>first</i>.</p>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a href="indexs10.html">Prev</a><EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Home</a></td>
<td width="40%" align="right"><EFBFBD><a href="indexs12.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left">Profiling &amp; Benchmarking<6E></td>
<td width="20%" align="center"><a href="index.html">Up</a></td>
<td width="40%" align="right"><EFBFBD>Tips</td>
</tr>
</table>
</div>
</body>
</html>

130
docs/kernelhacking-HOWTO/indexs12.html Normal file
View File

@@ -0,0 +1,130 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<title>Tips</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.40">
<link rel="home" href="index.html" title="Kernel Hacking HOWTO">
<link rel="up" href="index.html" title="Kernel Hacking HOWTO">
<link rel="previous" href="indexs11.html" title="The Linux Kernel Development Cycle">
<link rel="next" href="indexs13.html" title="More Information">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Tips</th></tr>
<tr>
<td width="20%" align="left">
<a href="indexs11.html">Prev</a><EFBFBD></td>
<th width="60%" align="center"><EFBFBD></th>
<td width="20%" align="right"><EFBFBD><a href="indexs13.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="sect1">
<a name="tips"></a><div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="tips"></a>Tips</h2></div></div>
<div class="sect2">
<a name="codingtips"></a><div class="titlepage"><div><h3 class="title">
<a name="codingtips"></a>Coding Tips</h3></div></div>
<p>This section is adapted from the old kernelhacking-HOWTO by Rusty Russell.</p>
<div class="sect3">
<a name="nomemprotection"></a><div class="titlepage"><div><h4 class="title">
<a name="nomemprotection"></a>No memory protection</h4></div></div>
<p>If you corrupt memory the whole machine will crash. Are you sure you can't do what you want in userspace? Consider the consequences of corrupting a RAM copy of a filesystems super block just before it is written back to disk... Consider the number of recent kernel releases with filesystem corruption bugs; it really isn't that hard to do!</p>
</div>
<div class="sect3">
<a name="nommx"></a><div class="titlepage"><div><h4 class="title">
<a name="nommx"></a>No floating point or MMX</h4></div></div>
<p>The FPU context is not saved; you would mess with some user process' FPU. If you really want to do this, you would have to explicitly save/restore the full FPU state (and avoid context switches). It is generally a bad idea; use fixed point arithmetic first.</p>
</div>
<div class="sect3">
<a name="stacklimit"></a><div class="titlepage"><div><h4 class="title">
<a name="stacklimit"></a>A rigid stack limit</h4></div></div>
<p>The stack is about 8K in 2.4, some is used by the process descriptor and the rest is shared with interrupts so you can't use it all. Avoid deep recursion and huge local arrays on the stack (allocate them dynamically instead).</p>
</div>
<div class="sect3">
<a name="portablecode"></a><div class="titlepage"><div><h4 class="title">
<a name="portablecode"></a>Portable Code</h4></div></div>
<p>The Linux kernel is portable; let's keep it that way. Your code should be 64-bit clean, and endian-independent (FIXME: expand on what this means in practice). You should also minimize CPU specific code, so inline assembly should be cleanly encapsulated and minimized (hence put in the architecture specific parts of the source tree) to ease porting.</p>
</div>
<div class="sect3">
<a name="provingcode"></a><div class="titlepage"><div><h4 class="title">
<a name="provingcode"></a>Proving Code</h4></div></div>
<p>Kernel programming is by nature challenging; you have few of the &quot;safety nets&quot; that user space programmers take for granted. The write-test cycle is also longer, meaning each line of kernel code takes longer to produce.</p>
<p>You can save yourself a lot of time by writing, debugging and testing as much of your code as possible in userspace before incorporating it into the kernel. Obviously, not all code can be developed this way, but a significant proportion can.</p>
</div>
<div class="sect3">
<a name="codingstyle"></a><div class="titlepage"><div><h4 class="title">
<a name="codingstyle"></a>Coding Style</h4></div></div>
<p>Hopefully, you will be aiming to get some of your code into the kernel at some stage. Even if you don't, there is a good chance you will post some of your code to the Linux Kernel Mailing List at some stage, perhaps as part of a request for help, after you have done your homework of course. You can improve the chances of a successful submission/help request by using the &quot;right&quot; coding style.</p>
<p>Understandably, Linus wants a consistent coding style throughout the source tree, so expects contributions that follow his preferred conventions. Although you may not agree with them, you had better get used to using them! Take a good at and inwardly digest <tt>Documentation/CodingStyle</tt>.</p>
</div>
<div class="sect3">
<a name="commentingcode"></a><div class="titlepage"><div><h4 class="title">
<a name="commentingcode"></a>Commenting Code</h4></div></div>
<p>Your emphasis here should be on explaining <i>why</i> your code does what it does, not <i>how</i>. If you feel the need to explain how your code works, consider re-writing it! You may find it helpful to deliberately over comment your code during development/debugging then trim it back before submission. The idea here is that the comments may jog your memory during the debugging phase, concerning logic, approach, rationale and assumptions used as the code was written.</p>
</div>
<div class="sect3">
<a name="protectdatastructures"></a><div class="titlepage"><div><h4 class="title">
<a name="protectdatastructures"></a>Protect Data Structures</h4></div></div>
<p>During development it is often a good idea to protect important data structures with &quot;magic numbers&quot;. Magic numbers consist of a field in the data structure which holds a random number, of your choice. When accessing or modifying the data structure, the magic number field can be checked for the expected value. If the correct value is not found, the data structure may have been corrupted, or the pointer to that data structure may be corrupted.</p>
<p>Magic numbers can be used to detect critical conditions and take appropriate action e.g. invoke an &quot;Oops&quot;. Suppose that the copy of a filesystems super block in memory has become corrupted by an array over-run. Writing that corrupted data structure back to the disk would catastrophic. If the data structure had been protected by a magic number, the corruption would probably have been detected and the disastrous write prevented. For super critical data structures, it may be worth placing two different magic numbers, one at the start and one at the end.</p>
<p>A list of magic numbers already in use can be found in <tt>~/Documentation/magic-number.txt</tt>. If you use any magic numbers, you should add them to the list, especially for code that may be submitted.</p>
</div>
</div>
<div class="sect2">
<a name="gendevtips"></a><div class="titlepage"><div><h3 class="title">
<a name="gendevtips"></a>General Development Tips</h3></div></div>
<div class="sect3">
<a name="keepalogbook"></a><div class="titlepage"><div><h4 class="title">
<a name="keepalogbook"></a>Keep a log book</h4></div></div>
<p>It is good practice to keep a step by step record of your work. Eventually, you will need all the juicy details of something you did two months ago and unless you happen to be gifted with an exceptional memory, recalling everything will be near on impossible. It is usually the &quot;gotchas&quot; that are especially valuable later on. A detailed work log can also be very useful when it comes to helping another member of the kernel community. The Kernel debugging part of this document started life as hand written notes in a log book!</p>
<p>Whether you maintain a hard, written copy or an electronic copy is up to you; both approaches have advantages.</p>
</div>
<div class="sect3">
<a name="maintstablesys"></a><div class="titlepage"><div><h4 class="title">
<a name="maintstablesys"></a>Maintaining a stable system</h4></div></div>
<p>Staying on the bleeding edge of kernel development is a risky business, however it is possible to contribute to current kernel development and minimise the risk of serious problems by:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46575304"></a>Making regular backups.</p></li>
<li><p>
<a name="id46575308"></a>Exercising caution before applying incremental patches. Obviously, more caution should be exercised for more critical systems.</p></li>
</ul></div>
<p>More to come on this, possibly a flow diagram of recommended practice.</p>
</div>
<div class="sect3">
<a name="rsi"></a><div class="titlepage"><div><h4 class="title">
<a name="rsi"></a>Avoiding RSI</h4></div></div>
<p>Mention of RSI (Repetitive Strain Injury) may seem out of place in this document. Unfortunately, some of the most talented, long term contributors to the kernel are plagued by RSI; you should take note of this and take appropriate preventive action.</p>
<p>One of the best sources of information on this subject is the <a href="http://www.tifaq.com/" target="_top">Typing Injury FAQ</a>.</p>
</div>
<div class="sect3">
<a name="firstproject"></a><div class="titlepage"><div><h4 class="title">
<a name="firstproject"></a>Choosing Your First Project</h4></div></div>
<p>Some people will be reading this document simply out of interest or to find out if kernel programming is of interest. Others may have a particular goal in mind; writing a new device driver or filesystem perhaps. Whichever scenario is true of you, this chapter contains information relevant to those thinking of embarking on their first kernel programming project.</p>
</div>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a href="indexs11.html">Prev</a><EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Home</a></td>
<td width="40%" align="right"><EFBFBD><a href="indexs13.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left">The Linux Kernel Development Cycle<6C></td>
<td width="20%" align="center"><a href="index.html">Up</a></td>
<td width="40%" align="right"><EFBFBD>More Information</td>
</tr>
</table>
</div>
</body>
</html>

106
docs/kernelhacking-HOWTO/indexs13.html Normal file
View File

@@ -0,0 +1,106 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<title>More Information</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.40">
<link rel="home" href="index.html" title="Kernel Hacking HOWTO">
<link rel="up" href="index.html" title="Kernel Hacking HOWTO">
<link rel="previous" href="indexs12.html" title="Tips">
<link rel="next" href="indexs14.html" title="Getting Help">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">More Information</th></tr>
<tr>
<td width="20%" align="left">
<a href="indexs12.html">Prev</a><EFBFBD></td>
<th width="60%" align="center"><EFBFBD></th>
<td width="20%" align="right"><EFBFBD><a href="indexs14.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="sect1">
<a name="moreinfo"></a><div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="moreinfo"></a>More Information</h2></div></div>
<div class="sect2">
<a name="srccodedocs"></a><div class="titlepage"><div><h3 class="title">
<a name="srccodedocs"></a>Source code docs</h3></div></div>
<p>make htmldocs</p>
<p>Documentation/kernel-docs.txt</p>
<p>Other kernel docs</p>
</div>
<div class="sect2">
<a name="links"></a><div class="titlepage"><div><h3 class="title">
<a name="links"></a>Links</h3></div></div>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46575382"></a><a href="http://www.kernelnewbies.org" target="_top">kernelnewbies</a>
</p></li>
<li><p>
<a name="id46575392"></a><a href="http://www.kerneltrap.com" target="_top">kerneltrap</a>
</p></li>
<li><p>
<a name="id46575396"></a><a href="http://www.lwn.net" target="_top">Linux Weekly News</a>
</p></li>
<li><p>
<a name="id46575409"></a><a href="http://www.dit.upm.es/~jmseyas/linux/kernel/hackers-docs.html" target="_top">Kernel Hackers Docs</a>
</p></li>
</ul></div>
</div>
<div class="sect2">
<a name="books"></a><div class="titlepage"><div><h3 class="title">
<a name="books"></a>Books</h3></div></div>
<div class="sect3">
<a name="cprogramming"></a><div class="titlepage"><div><h4 class="title">
<a name="cprogramming"></a>C Programming</h4></div></div>
<p>TODO</p>
</div>
<div class="sect3">
<a name="osconcepts"></a><div class="titlepage"><div><h4 class="title">
<a name="osconcepts"></a>OS concepts</h4></div></div>
<p>TODO</p>
</div>
</div>
<div class="sect2">
<a name="web"></a><div class="titlepage"><div><h3 class="title">
<a name="web"></a>Web</h3></div></div>
<p>Other sources of information:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46575464"></a><a href="http://foldoc.doc.ic.ac.uk" target="_top">http://foldoc.doc.ic.ac.uk</a>
</p></li>
<li><p>
<a name="id46575468"></a><a href="http://hissa.nist.gov/dads/" target="_top">the Dictionary of Algorithms, Data Structures, and Problems</a>
</p></li>
<li><p>
<a name="id46575471"></a><a href="http://www.xanalys.com/software_tools/mm/glossary/full.html" target="_top">the Memory Management Glossary</a>
</p></li>
<li><p>
<a name="id46575486"></a>The Jargon File <a href="http://www.tuxedo.org/~esr/jargon/" target="_top">http://www.tuxedo.org/~esr/jargon/</a> or <a href="http://www.jargon.org/" target="_top">http://www.jargon.org/</a>
</p></li>
</ul></div>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a href="indexs12.html">Prev</a><EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Home</a></td>
<td width="40%" align="right"><EFBFBD><a href="indexs14.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left">Tips<EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Up</a></td>
<td width="40%" align="right"><EFBFBD>Getting Help</td>
</tr>
</table>
</div>
</body>
</html>

82
docs/kernelhacking-HOWTO/indexs14.html Normal file
View File

@@ -0,0 +1,82 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<title>Getting Help</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.40">
<link rel="home" href="index.html" title="Kernel Hacking HOWTO">
<link rel="up" href="index.html" title="Kernel Hacking HOWTO">
<link rel="previous" href="indexs13.html" title="More Information">
<link rel="next" href="indexs15.html" title="FAQ">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Getting Help</th></tr>
<tr>
<td width="20%" align="left">
<a href="indexs13.html">Prev</a><EFBFBD></td>
<th width="60%" align="center"><EFBFBD></th>
<td width="20%" align="right"><EFBFBD><a href="indexs15.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="sect1">
<a name="gettinghelp"></a><div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="gettinghelp"></a>Getting Help</h2></div></div>
<div class="sect2">
<a name="mailinglists"></a><div class="titlepage"><div><h3 class="title">
<a name="mailinglists"></a>mailing lists</h3></div></div>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46575517"></a><a href="http://www.kernelnewbies.org" target="_top">Kernelnewbies</a>, Consists of a web page, IRC channel (\#kernelnewbies on irc.openprojects.net) and a mailing list.</p></li>
<li>
<p>
<a name="id46575529"></a><a href="http://www.tux.org/lkml" target="_top">Linux-kernel</a>, a high volume list, post to it only after all other options are exhausted. It certainly should not be your &quot;first port of call&quot;. Please go down this check list before posting.</p>
<div class="orderedlist"><ol type="1">
<li><p>
<a name="id46575547"></a>Read the <a href="http://www.tux.org/lkml" target="_top">FAQ</a>
</p></li>
<li><p>
<a name="id46575554"></a>Search the <a href="http://www.uwsg.indiana.edu/hypermail/linux/kernel/index.html" target="_top">archives</a> **FIXME** replace with aimsgroup URL</p></li>
<li><p>
<a name="id46575569"></a>Read the latest <a href="http://kt.zork.net/" target="_top">kernel-traffic</a>, to see if the problem you are experiencing is a known issue.</p></li>
<li><p>
<a name="id46575580"></a>Do your homework first (e.g. read appropriate man pages, guides and HOWTO documents)</p></li>
<li><p>
<a name="id46575585"></a>Read &amp; follow <a href="http://www.tuxedo.org/~esr/faqs/smart-questions.html" target="_top">this posting guide</a>
</p></li>
<li><p>
<a name="id46575591"></a>Polish your message before posting; keep it short but informative.</p></li>
</ol></div>
</li>
</ul></div>
</div>
<div class="sect2">
<a name="irc"></a><div class="titlepage"><div><h3 class="title">
<a name="irc"></a>IRC</h3></div></div>
<p>#kernelnewbies on irc.openprojects.net</p>
<p>Please add to this list!</p>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a href="indexs13.html">Prev</a><EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Home</a></td>
<td width="40%" align="right"><EFBFBD><a href="indexs15.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left">More Information<6F></td>
<td width="20%" align="center"><a href="index.html">Up</a></td>
<td width="40%" align="right"><EFBFBD>FAQ</td>
</tr>
</table>
</div>
</body>
</html>

61
docs/kernelhacking-HOWTO/indexs15.html Normal file
View File

@@ -0,0 +1,61 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<title>FAQ</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.40">
<link rel="home" href="index.html" title="Kernel Hacking HOWTO">
<link rel="up" href="index.html" title="Kernel Hacking HOWTO">
<link rel="previous" href="indexs14.html" title="Getting Help">
<link rel="next" href="indexs16.html" title="To Do">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">FAQ</th></tr>
<tr>
<td width="20%" align="left">
<a href="indexs14.html">Prev</a><EFBFBD></td>
<th width="60%" align="center"><EFBFBD></th>
<td width="20%" align="right"><EFBFBD><a href="indexs16.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="sect1">
<a name="faq"></a><div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="faq"></a>FAQ</h2></div></div>
<p>If you would like to suggest a question (and hopefully an answer too) for this FAQ then send them to <a href="mailto:kh.howto@andyebling.clara.co.uk?subject=KH-HOWTO%20QUESTION" target="_top">me</a> with KH-HOWTO QUESTION in the subject.</p>
<div class="itemizedlist"><ul>
<li>
<p>
<a name="id46575628"></a>Q: I want to get started doing something useful, which project should I help out on?</p>
<p>A: The best thing to do is subscribe to <a href="http://www.kernelnewbies.org" target="_top">the kernelnewbies mailing list</a> and ask if anyone would like to take a newbie onto their project</p>
</li>
<li>
<p>
<a name="id46575642"></a>Q: Can you set me some kernel programming assignments?</p>
<p>A: Sorry, I simply don't have time to do this for everyone who asks. I hope to add some more examples followed by tasks/assignments to each section of the document in the near future.</p>
</li>
</ul></div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a href="indexs14.html">Prev</a><EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Home</a></td>
<td width="40%" align="right"><EFBFBD><a href="indexs16.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left">Getting Help<6C></td>
<td width="20%" align="center"><a href="index.html">Up</a></td>
<td width="40%" align="right"><EFBFBD>To Do</td>
</tr>
</table>
</div>
</body>
</html>

55
docs/kernelhacking-HOWTO/indexs16.html Normal file
View File

@@ -0,0 +1,55 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<title>To Do</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.40">
<link rel="home" href="index.html" title="Kernel Hacking HOWTO">
<link rel="up" href="index.html" title="Kernel Hacking HOWTO">
<link rel="previous" href="indexs15.html" title="FAQ">
<link rel="next" href="indexs17.html" title="Glossary">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">To Do</th></tr>
<tr>
<td width="20%" align="left">
<a href="indexs15.html">Prev</a><EFBFBD></td>
<th width="60%" align="center"><EFBFBD></th>
<td width="20%" align="right"><EFBFBD><a href="indexs17.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="sect1">
<a name="todo"></a><div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="todo"></a>To Do</h2></div></div>
<p>This section describes ideas and sections that I hope to add in the not to distant future. The aim here is to avoid being sent the same suggestion 101 times!</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46575678"></a>Road map of planned additions.</p></li>
<li><p>
<a name="id46575683"></a>How to use printk and syslog.</p></li>
</ul></div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a href="indexs15.html">Prev</a><EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Home</a></td>
<td width="40%" align="right"><EFBFBD><a href="indexs17.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left">FAQ<EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Up</a></td>
<td width="40%" align="right"><EFBFBD>Glossary</td>
</tr>
</table>
</div>
</body>
</html>

600
docs/kernelhacking-HOWTO/indexs17.html Normal file
View File

@@ -0,0 +1,600 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<title>Glossary</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.40">
<link rel="home" href="index.html" title="Kernel Hacking HOWTO">
<link rel="up" href="index.html" title="Kernel Hacking HOWTO">
<link rel="previous" href="indexs16.html" title="To Do">
<link rel="next" href="indexs17.html#id46575701" title="Glossary">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Glossary</th></tr>
<tr>
<td width="20%" align="left">
<a href="indexs16.html">Prev</a><EFBFBD></td>
<th width="60%" align="center"><EFBFBD></th>
<td width="20%" align="right"><EFBFBD><a href="indexs17.html#id46575701">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="sect1">
<a name="glossary"></a><div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="glossary"></a>Glossary</h2></div></div>
<p>This part of the document will remain a random to-do list until I figure out how to do a glossary properly in SGML!</p>
<p>Please send suggestions.</p>
<div id="id46575701" class="glossary">
<div class="titlepage"><div><h2 class="title">
<a name="id46575701"></a>Glossary</h2></div></div>
<dl>
<dt><a name="id46575702">2Q algorithm</a></dt>
<dd><p>MM algorithm based on two areas, one managed as a FIFO queue, and one as an LRU list.</p></dd>
<dt><a name="id46575713">8259 PIC</a></dt>
<dd><p>Outdated Programmable Interrupt Controller present on Intel hardware.</p></dd>
<dt><a name="id46575722">ABI</a></dt>
<dd><p>Application Binary Interface; the interface of passed structures between the user processes (and libraries) and the kernel. For compatibility, it is important that these remain as static as possible (i.e. making sure that variables and structure members have the same bytesize as before, and in the same ordering). Occasionally breakage is necessary, requiring re-compilation of the user-space sources (note that this does not affect source-compatibility; that is a separate issue).</p></dd>
<dt><a name="id46575735">ACPI</a></dt>
<dd><p>Advanced Configuration and Power Interface - replacement for APM that has the advantage of allowing O/S control of power management facilities.</p></dd>
<dt><a name="id46575744">AGI</a></dt>
<dd><p>Address Generation Interlocking, on x86. When execution of an instruction requires an address resulting from a non-completed instruction, the CPU must wait - this is known as an AGI stall.</p></dd>
<dt><a name="id46575754">AGP</a></dt>
<dd><p>Accelerated Graphics Port, on x86 boxes.</p></dd>
<dt><a name="id46575763">anonymous</a></dt>
<dd><p>Generally, used for something which doesn't have the usual associated object. For example an anonymous address space is not interested in user address space (that is, no process context). Some common ones are:</p></dd>
<dt><a name="id46575773">Anonymous page</a></dt>
<dd><p>A page of memory that is not associated with a file on a file system. This can come from expanding the process's data segment with brk(), shared memory segments, or mmap() with a MAP_ANON or MAP_PRIVATE flag. MAP_PRIVATE, although it maps in data from a file, is considered anonymous because any changes do not get written back to the file (any dirty pages have to be moved to swap if the page is freed from main memory).</p></dd>
<dt><a name="id46575785">Anonymous buffer</a></dt>
<dd><p>The buffer cache contains buffers of data on their way to/from the disk. An anonymous buffer is not associated with a file. One example of this is data from a deleted file - it will not be written to any file, but is kept around until it is flushed.</p></dd>
<dt><a name="id46575796">APIC</a></dt>
<dd><p>See local APIC and IO-APIC.</p></dd>
<dt><a name="id46575804">APM</a></dt>
<dd><p>Advanced Power Management, power management standard superseded by ACPI. APM and SMP just don't mix.</p></dd>
<dt><a name="id46575813">ARP</a></dt>
<dd><p>This is an acronym for the Address Resolution Protocol and this is how a network machine associates an IP Address with a hardware address.</p></dd>
<dt><a name="id46575823">ASN.1</a></dt>
<dd><p>Abstract Syntax Notation, a protocol for structured data, used, for example, in the Q.3 management protocol.</p></dd>
<dt><a name="id46575832">ast</a></dt>
<dd><p>Professor Andrew S. Tanenbaum, writer of MINIX and several essential O/S books.</p></dd>
<dt><a name="id46575841">ATAPI</a></dt>
<dd><p>ATA Packet Interface, used by most CD-ROMs, and other devices.</p></dd>
<dt><a name="id46575850">balancing</a></dt>
<dd><p>Technique used in the VM code, referring to balancing various parameters such as the number of pages currently free, to avoid thrashing and other bad memory capacity artefacts. See zones, kswapd bug.</p></dd>
<dt><a name="id46575860">BAR</a></dt>
<dd><p>Base Address Registers, for PCI devices.</p></dd>
<dt><a name="id46575868">BCD</a></dt>
<dd><p>Binary-Coded Decimal - see a textbook.</p></dd>
<dt><a name="id46575877">bigmem</a></dt>
<dd><p>See highmem.</p></dd>
<dt><a name="id46575885">big lock</a></dt>
<dd><p>kernel_lock, which locks the entire kernel from entry (no other task may run in the kernel code). It is recursive per process and dropped automatically when a process gives up the CPU, then regained on wake-up, in contrast to other spinlocks.</p></dd>
<dt><a name="id46575896">bit error</a></dt>
<dd><p>Used colloquially to mean a single bit error in some memory address. Often due to faulty memory (ECC memory can correct single bit errors). Often results in fake Oopsen, with addresses like 0x0008000. Also seen are values some small offset from zero, plus a bit error, which is where the value passed a NULL check due to the bit error, and then the kernel tried to access a structure member by means of the pointer, leading to the offset.</p></dd>
<dt><a name="id46575908">block bitmap</a></dt>
<dd><p>In UNIX-like filesystems, the usage of disks blocks is recorded in the block bitmap, where each set bit indicates a specific allocated block.</p></dd>
<dt><a name="id46575918">bottom-half handler</a></dt>
<dd><p>A set of standard kernel threads that execute tasks on a queue that have been registered with that type of bottom-half handler for execution. The code is run on return to user space or at the end of a hardware interrupt. In 2.3.43 a more general solution with softirqs and tasklets was implemented. Sometimes abbreviated to &quot;bh&quot;, which should not be confused with buffer head, which is also abbreviated to &quot;bh&quot;.</p></dd>
<dt><a name="id46575930">bounce buffer</a></dt>
<dd><p>An intermediate buffer. Used for example, in &quot;faking&quot; alignment to a client from non-aligned resources.</p></dd>
<dt><a name="id46575939">brlocks</a></dt>
<dd><p>Big-reader locks, used when there are many contending for read access to a resource, and very few contending for writes (thus the balance is towards very fast read locking, and very slow write locking).</p></dd>
<dt><a name="id46575949">BSP</a></dt>
<dd><p>BootStrap Processor, or the CPU which enables the other CPUs in an SMP system.</p></dd>
<dt><a name="id46575958">bss</a></dt>
<dd><p>Block storage segment. This is the memory mapping section containing the data allocated for a binary image at execution time. Also known as &quot;Block Started by Symbol&quot; and &quot;Bull-Shit Storage&quot;.</p></dd>
<dt><a name="id46575968">BTB</a></dt>
<dd><p>Branch Target Buffer - on x86 processors, the cache of recent conditional jump results.</p></dd>
<dt><a name="id46575977">buddy allocator</a></dt>
<dd><p>The memory allocation scheme used in the kernel. A vector of lists of free pages is kept, ordered by the size of the chunk (in powers of two). When a chunk is allocated, it is removed from the relevant list. When a chunk is freed back to the free pages pool, it is placed in the relevant list, starting from the top. If it is physically contiguous with a present chunk, they are merged and placed in the list above (i.e. where the chunks are twice the size), and this operation percolates up the vector. As regions are merged whenever possible, this design helps to reduce memory fragmentation. FIXME</p></dd>
<dt><a name="id46575991">buffer cache</a></dt>
<dd><p>The buffer cache is a hash table of buffers, indexed by device and block number. LRU lists are maintained for the buffers in the various states, with separate lists for buffers of different sizes. With 2.3's unification of the buffer and page caches, each buffer head points to part or all of a page structure, through which the buffer's actual contents are available. FIXME</p></dd>
<dt><a name="id46576006">buffer head</a></dt>
<dd><p>A structure containing information on I/O for some page in real memory. A buffer can be locked during I/O, or in several other states depending on its usage or whether it is free. Each buffer is associated with one page, but every page may have several buffers (consider the floppy on x86, where the I/O block size is 512 bytes, but each page is commonly 4096 bytes).</p></dd>
<dt><a name="id46576018">BUG()</a></dt>
<dd><p>Used in kernel code in tests for &quot;impossible&quot; conditions. Signify a kernel bug or faulty hardware.</p></dd>
<dt><a name="id46576027">bus mastering</a></dt>
<dd><p>Giving a card on a bus (e.g. ISA,PCI) the ability to read/write directly to main memory. This is how DMA is performed on PCI busses.</p></dd>
<dt><a name="id46576036">byte sex</a></dt>
<dd><p>Endianness.</p></dd>
<dt><a name="id46576044">cache affinity</a></dt>
<dd><p>Where the cache of a CPU represents the current memory set used by a task, there is said to be cache affinity with that task. A good thing if the task is regularly scheduled on that CPU. See processor affinity.</p></dd>
<dt><a name="id46576055">cache coherency</a></dt>
<dd><p>On an SMP system, ensuring that the local memory cache of each CPU is consistent with respect to the values which may be stored in other CPUs' caches, avoiding coherency problems such as the &quot;lost update&quot;. This is achieved by the hardware in concert with the operating system.</p></dd>
<dt><a name="id46576066">cache line</a></dt>
<dd><p>A section of the hardware cache, around 32 bytes large. Kernel structures are often designed such that the commonly-accessed members all fit into one cache-line, which reduces cache pollution. Structures such as this are cache line aligned.</p></dd>
<dt><a name="id46576076">cache ping-pong</a></dt>
<dd><p>A hardware phenomenon in an SMP system, where two tasks on different CPUs are both accessing the same physical memory in a cache line. This means as each task runs, when it changes the memory, it must invalidate the other CPU's relevant cache line (to ensure cache coherency). Then, when the task on the other CPU runs, it must reload the cache line (as it's set invalid), before changing it. Repeat ad jocularum. A bad thing (TM). A common reason for putting a lock on a different cache line than the data mutexed by the lock : then the &quot;other&quot; task can grab and drop the lock without having to necessarily invalidate the cache line on the first CPU. FIXME</p></dd>
<dt><a name="id46576090">cache pollution</a></dt>
<dd><p>Where during execution of a task, another task is scheduled onto that CPU which disrupts useful lines of the current cache contents, which will be used soon. That is, cache pollution is a non-optimal situation where the other process would have been bettered scheduled on a different CPU or at a different time. The aim is to minimise the need to replace cache lines, obviously increasing efficiency.</p></dd>
<dt><a name="id46576102">call gate</a></dt>
<dd><p>x86 hardware support for mode switch to kernel (i.e. system call). In Linux, int 0x80 will trigger the call gate.</p></dd>
<dt><a name="id46576112">CAP_</a></dt>
<dd><p>These are defined names of capabilities for specific tasks provided by the kernel, e.g. CAP_SYS_NICE.*</p></dd>
<dt><a name="id46576121">chroot jail</a></dt>
<dd><p>A process under the aegis of a chroot() syscall is in a chroot jail, and cannot access the file system above its notion of root directory /.</p></dd>
<dt><a name="id46576130">cli/sti</a></dt>
<dd><p>x86 assembler instructions for disabling and enabling interrupts, respectively. There are CPU-local and global variants of these. Code running with interrupts disabled must be fast, for obvious reasons (this is called interrupt latency).</p></dd>
<dt><a name="id46576141">CML2</a></dt>
<dd><p>Eric Raymond's proposal for a replacement to the current kernel build system. See http://www.tuxedo.org/~esr/kbuild.</p></dd>
<dt><a name="id46576150">cold cache</a></dt>
<dd><p>A cache whose content is invalid or irrelevant with respect to some task to be run.</p></dd>
<dt><a name="id46576159">completion ports</a></dt>
<dd><p>I/O interface used in O/S's such as Windows NT. Userspace notifies the kernel of each file descriptor the program is interested. The O/S uses a callback for each fd to indicate that I/O is ready.</p></dd>
<dt><a name="id46576169">contention</a></dt>
<dd><p>Where two tasks each want an exclusive resource. You may hear talk of, for example, spinlock contention, which is where one or more tasks is commonly busy-waiting for a spinlock to become unlocked, as it is being taken by other tasks.</p></dd>
<dt><a name="id46576179">context switch</a></dt>
<dd><p>Refers to the changes necessary in the CPU when the scheduler schedules a different process to run on the CPU. This involves invalidating the TLB, loading the registers with the saved values, etc. There is an associated cost with such a switch, so it is best to avoid unnecessary context switch when possible. Note that the division of kernel-mode and user-mode means a similar, but simpler, operation is necessary when a syscall moves into kernel mode. However this is not called a context switch, as the mode switch doesn't change the current process. See lazy TLB. One good of feature of Linux is its extremely low context and mode switch cost, compared to an operating system like Solaris.</p></dd>
<dt><a name="id46576194">COW</a></dt>
<dd><p>Copy-On-Write, efficiency method where a page or other resource is shared until an attempt to write is made. In that case a copy is made, and the write is done to the copy.</p></dd>
<dt><a name="id46576204">CPL</a></dt>
<dd><p>Current Privilege Level. FIXME</p></dd>
<dt><a name="id46576212">critical path</a></dt>
<dd><p>A vital code path which should be optimised for the common case. Critical paths are executed frequently and form the important trunk routes of various kernel operations. An example would be buffer head manipulation during file I/O.</p></dd>
<dt><a name="id46576223">css</a></dt>
<dd><p>Code storage segment, aka text section. This is the memory mapping containing the executable code (text) for a binary image.</p></dd>
<dt><a name="id46576232">Directed Acyclic Graph</a></dt>
<dd><p>FIXME</p></dd>
<dt><a name="id46576240">dancing makefiles</a></dt>
<dd><p>An experimental new Makefile set up for configuring and compiling the kernel, written by Michael Elizabeth Chastain.</p></dd>
<dt><a name="id46576250">dcache</a></dt>
<dd><p>The cache of dentry structures. Under UNIX an entry in a particular directory must be searched for linearly, so even if the disk block containing the directory entry list is in-core, there is an associated cost. The dcache stores recent results of these searches which in general speeds up these disk searches by a large factor. Recent 2.3 work uses the dentries to allow multiple mounting, union mount, and more. The hardware data cache is usually referred to as the D-cache.</p></dd>
<dt><a name="id46576262">deadlock</a></dt>
<dd><p>Any of a number of situations where two or more processes cannot proceed because they are both waiting for the other to release some resource. FIXME(give good references).</p></dd>
<dt><a name="id46576272">delayed write</a></dt>
<dd><p>See write behind.</p></dd>
<dt><a name="id46576280">demand zero</a></dt>
<dd><p>In demand paging, where the page is to be zeroed when actually created (common case: bss segment of an executable image, which is uninitialised heap data for the executable). Also called ZFOD.</p></dd>
<dt><a name="id46576291">dentry</a></dt>
<dd><p>Directory entry, in-core structure defining a file's details: inode, parent dentry etc. Cached in a hash table indexed by hashed filename (see dcache).</p></dd>
<dt><a name="id46576300">DF</a></dt>
<dd><p>IP packet bit indicating it should not be fragmented. The remote host will return ICMP notifications if the packet had to be split anyway, and these are used in MTU discovery.</p></dd>
<dt><a name="id46576310">directory notification</a></dt>
<dd><p>Provides hooks for notifying tasks when the contents of a directory has changed. Note &quot;contents&quot; can refer to dentries, the file inodes, or even the file contents themselves (file notification).</p></dd>
<dt><a name="id46576320">DOD</a></dt>
<dd><p>Dial-On-Demand for PPP connections over a standard telephone line. </p></dd>
<dt><a name="id46576329">drop behind</a></dt>
<dd><p>In stream I/O conditions, data that has already been read and processed is not needed again. The VM ideally should recognise this and mark the used pages as unneeded, so they can be discarded first. This technique is called &quot;drop behind&quot;.</p></dd>
<dt><a name="id46576339">dss</a></dt>
<dd><p>Data storage segment, aka data section. This is the memory mapping containing the initialised data for a binary image.</p></dd>
<dt><a name="id46576348">dual-issue</a></dt>
<dd><p>Processors such as the Pentium Pro, that can decode and execute two instructions simultaneously.</p></dd>
<dt><a name="id46576358">dupe</a></dt>
<dd><p>Abbrev. fr. duplication.</p></dd>
<dt><a name="id46576366">dword</a></dt>
<dd><p>Double word, i.e. 4 bytes on x86.</p></dd>
<dt><a name="id46576374">EA</a></dt>
<dd><p>See extended attributes.</p></dd>
<dt><a name="id46576383">eager coalescing</a></dt>
<dd><p>What the buddy allocator currently does, i.e. merge adjacent blocks as soon as possible.</p></dd>
<dt><a name="id46576392">edge-triggered interrupt</a></dt>
<dd><p>The interrupt is triggered by the rising or falling edge of the interrupt line. This makes IRQ line sharing difficult, as an edge may occur while an ISR is running, and it could be easily missed; to allow sharing level-triggered interrupts are usually used.</p></dd>
<dt><a name="id46576403">EIP</a></dt>
<dd><p>Extended Instruction Pointer. This register contains the PC value of a task, that is, it points to the next instruction to be fetched, decoded etc.</p></dd>
<dt><a name="id46576412">elevator algorithm</a></dt>
<dd><p>This algorithm, often used in disk accesses, keeps an ordered list of requests. When the current request on the disk (e.g. the disk block) has been satisfied, the next strictly greater request on the list is dealt with. When a new request arrives, it is inserted into the ordered list in position (e.g. if the new requested block number is less than the current handled request, it goes before it in the list). When reaching the end of the list, the elevator changes direction, and the situation is reversed.</p></dd>
<dt><a name="id46576430">EPIC</a></dt>
<dd><p>Explicitly-Parallel Instruction set Computing, an instruction set architecture where every dependency for an instruction is encoded into the instruction itself. This has the potential to be faster as the compiler can encode the data dependencies in the instructions.</p></dd>
<dt><a name="id46576441">exponential back-off</a></dt>
<dd><p>A general algorithm for dealing with contention cases; for example, collisions on a network bus, or contention for a spinlock.</p></dd>
<dt><a name="id46576450">extended attributes</a></dt>
<dd><p>Also known as multi-part or multi-stream files, files with extended attributes deviate from the principle of files being a simple single data stream. An example of extended attributes is the Macintosh's &quot;resource fork&quot;, which is associated with a specific file (known as the &quot;data fork&quot;).</p></dd>
<dt><a name="id46576461">fair scheduler</a></dt>
<dd><p>A scheduler which ensures fairness between users, such that a user's process count and associated cost only impacts that user, rather than the whole system as currently. Rik van Riel and Borislav Deianov have both produced different patches to implement this.</p></dd>
<dt><a name="id46576472">false sharing</a></dt>
<dd><p>On SMP caches, when two parts of single block are accessed, neither of which collide with the other, the cache coherency protocol may not be able to detect this, and mark the block as &quot;shared&quot; even when it isn't. This is known as false sharing.</p></dd>
<dt><a name="id46576482">fastpath</a></dt>
<dd><p>The code path most commonly taken, often optimised heavily at the expense of less frequently-taken blocks of code. This is the reason you see so many gotos in core functions - it produces common-path code far more efficient than an optimising compiler can manage.</p></dd>
<dt><a name="id46576493">fd</a></dt>
<dd><p>file descriptor.</p></dd>
<dt><a name="id46576501">filemap</a></dt>
<dd><p>The mapping of a file's contents into memory.</p></dd>
<dt><a name="id46576510">fixed mmap</a></dt>
<dd><p>A user-space request for a mmap starting at a fixed virtual address. Generally not useful or guaranteed to work; a notable exception is overlayed mmaps, where a mmaped area has further mmaps of different types at fixed positions in the map.</p></dd>
<dt><a name="id46576520">FQDN</a></dt>
<dd><p>Fully-Qualified Domain Name, e.g. martyr.darrenemerson.co.uk.</p></dd>
<dt><a name="id46576529">GART</a></dt>
<dd><p>For AGP setups, Graphics Aperture Relocation Table.</p></dd>
<dt><a name="id46576538">gdoc</a></dt>
<dd><p>GNOME's source documentation system (similar to javadoc). Available by CVS from gnome. Kernel driver interface descriptions, built from source using gdoc, are currently being written in 2.3.</p></dd>
<dt><a name="id46576548">gdt</a></dt>
<dd><p>Global Descriptor Table. Something to do with x86 memory segmentation I think (FIXME). See ldt.</p></dd>
<dt><a name="id46576557">get</a></dt>
<dd><p>In the kernel, often means &quot;get a reference to&quot;. This may be as simple as incrementing a usage count, or it may imply attempting to retrieve an object from a cache of some sort, or allocating kernel memory. See put.</p></dd>
<dt><a name="id46576567">GKHI</a></dt>
<dd><p>Generalised Kernel Hook Infrastructure, an IBM patch to implement hooks into the kernel code.</p></dd>
<dt><a name="id46576576">group descriptor</a></dt>
<dd><p>On-disk filesystem structure, containing information for a block group, such as the inode bitmap and block bitmap.</p></dd>
<dt><a name="id46576585">HID</a></dt>
<dd><p>Human Interface Device (for USB).</p></dd>
<dt><a name="id46576594">highmem</a></dt>
<dd><p>On the x86 platform, memory addresses accessed using Intel's Physical Address Extension, which allows real memory of up to 64Gb on IA32. Only certain things can be stored in this space (FIXME: only userspace ? or what ? no bh or irqhandler can use it ...)</p></dd>
<dt><a name="id46576604">hton</a></dt>
<dd><p>Possibly byte-swapping conversion from host-endian to network-endian format. The network is big-endian.</p></dd>
<dt><a name="id46576614">IBCS</a></dt>
<dd><p>A standard for executable image interfacing (syscalls etc.). This is orthogonal to binary image file format standards such as ELF.</p></dd>
<dt><a name="id46576623">icache</a></dt>
<dd><p>On lkml, this almost always refers to the inode cache, rather than the hardware instruction cache (I-cache).</p></dd>
<dt><a name="id46576632">IETF</a></dt>
<dd><p>Internet Engineering Task Force, a standards organisation for protocols used on the Internet.</p></dd>
<dt><a name="id46576641">IKD</a></dt>
<dd><p>Integrated Kernel Debugger. A patched version of the kernel containing additional facilities for debugging the kernel.</p></dd>
<dt><a name="id46576650">ILP</a></dt>
<dd><p>Instruction-Level Parallelism, i.e. executing more than one instruction at once. See dual-issue.</p></dd>
<dt><a name="id46576660">incestuous</a></dt>
<dd><p>What you might expect: code with knowledge of used code's internals beyond the API. This breaks modularity, increases complexity and causes bugs, and a design goal is to minimise this behaviour.</p></dd>
<dt><a name="id46576670">inode</a></dt>
<dd><p>As per UNIX, the structure defining a file (except for the filename which is stored in the directory entry). The inode cache is a closed hash table indexed by superblock and inode number, and is only hit when the dentry lookup failed.</p></dd>
<dt><a name="id46576680">inode bitmap</a></dt>
<dd><p>In UNIX-like filesystems, the usage of on-disk inodes is recorded in the inode bitmap, where each set bit indicates a specific allocated inode.</p></dd>
<dt><a name="id46576690">insn</a></dt>
<dd><p>Abbrev. fr. &quot;instruction&quot;.</p></dd>
<dt><a name="id46576698">interrupt context</a></dt>
<dd><p>This is code executing in the kernel in response to a generated interrupt, without a process context. For more time-consuming work, a bottom-half handler task can be added to be executed at some later time.</p></dd>
<dt><a name="id46576708">interrupt gate</a></dt>
<dd><p>x86 hardware support for hardware interrupts. Interrupt gate facilities are provided to allow a known entry path from untrusted privilege levels to the interrupt routines.</p></dd>
<dt><a name="id46576718">IO-APIC</a></dt>
<dd><p>Receives interrupts external to a CPU (e.g. from a device) and routes them through the local APIC to the CPU.</p></dd>
<dt><a name="id46576727">iopl</a></dt>
<dd><p>I/O privilege level system call and bit in x86 EFLAGS register.</p></dd>
<dt><a name="id46576736">IPI</a></dt>
<dd><p>Inter-processor Interrupt. On SMP machines this refers to an interrupt sent between CPUs, indicating some event that the other CPU needs to be aware of, for example smp_invalidate_interrupt, which invalidates a CPU's TLB.</p></dd>
<dt><a name="id46576746">ISO9660</a></dt>
<dd><p>On-disk format often used for CDs. See also Joliet.</p></dd>
<dt><a name="id46576755">ISR</a></dt>
<dd><p>Interrupt Service Routine, or interrupt handler. Also, on x86 APICs, In-Service Register, confusingly enough.</p></dd>
<dt><a name="id46576764">jiffy</a></dt>
<dd><p>Basic packet of kernel time, around 10ms on x86. Related to HZ, the basic resolution of the operating system. The timer interrupt is raised each 10ms, which then performs some h/w timer related stuff, and marks a couple of bh's ready to run if applicable.</p></dd>
<dt><a name="id46576775">Joliet</a></dt>
<dd><p>Microsoft extension to ISO9660, commonly used.</p></dd>
<dt><a name="id46576783">journalling</a></dt>
<dd><p>A filesystem that writes all changes to some log file, to preserve filesystem consistency (for example, an inode's link count should equal the number of directory entries pointing to that inode). There are two types; FIXME log only metadata such as link count, whereas FIXME logs both meta-data and data, effectively writing all data twice. ext3, ReiserFS and XFS are all meta-data loggers, the second type are rare as the same effect can be achieved using RAID.</p></dd>
<dt><a name="id46576796">kiobuf</a></dt>
<dd><p>FIXME</p></dd>
<dt><a name="id46576804">kiovec</a></dt>
<dd><p>This allows user-space memory access from other contexts, such as in a bh. This also allows kernel drivers to set up DMA from a device directly to user-space pages.</p></dd>
<dt><a name="id46576814">kmalloc</a></dt>
<dd><p>Kernel memory allocation routine. See vmalloc. kmalloc() ensures physical address contiguity.</p></dd>
<dt><a name="id46576823">kswapd bug</a></dt>
<dd><p>Problems with VM balancing in late 2.3 kernels. People in a variety of situations found that the VM subsystem was far from optimal, leading to the kernel swapping daemon kswapd taking an inordinate amount of CPU resources; thrashing was also a common problem. Work is undergoing to fix these scenarios.</p></dd>
<dt><a name="id46576834">L1</a></dt>
<dd><p>See L2.</p></dd>
<dt><a name="id46576842">L2</a></dt>
<dd><p>The L2 (level 2) cache is a memory cache in the order of half a megabyte wide, located on the motherboard. The much faster L1 cache is in-CPU, but correspondingly smaller. x86 has a two-level cache, while some architectures such as Alpha AXP have an additional L3 cache. Often referred to is the memory hierarchy, which goes something like (with increasing latency and capacity, decreasing cost) registers, L1 cache, L2 cache, L3 cache, main memory, local mass storage device, network.</p></dd>
<dt><a name="id46576855">lazy TLB</a></dt>
<dd><p>Some tasks, such as kernel threads like kswapd, don't have a process context, which renders the costly invalidation of the TLB unnecessary (as the user-level page tables are not used). The task structure member mm indicates the user-level address space, which will be NULL for kernel threads. In this case active_mm indicates the used address space (kernel). These address spaces are known as anonymous. Note also that certain tasks may occasionally temporarily drop the user-level address space and have an anonymous address space for a short while.</p></dd>
<dt><a name="id46576869">ldt</a></dt>
<dd><p>Local Descriptor Table. The ldt is a per-process memory management table used on x86. See gdt.</p></dd>
<dt><a name="id46576878">lease</a></dt>
<dd><p>General term used in unreliably-connected components. A resource is given a lease which eventually expires. This means the connection can break, without leaving state hanging. NFS, being stateless, does not have the concept of leases.</p></dd>
<dt><a name="id46576888">level-triggered interrupt</a></dt>
<dd><p>Also level-sensitive. As used on PCI. PCI's ability to have multiple devices sharing a single interrupt line is made possible by its use of level-triggered interrupts. If interrupts were edge-triggered, it is possible that some of the incoming interrupts might be lost, for example if a second interrupt were to come in while the processor was still in the midst of processing a previous one, the processor would return from servicing the first interrupt but not be aware that a second interrupt had been asserted. With level-triggered interrupts, by contrast, the interrupt line remains active until specifically deactivated by an ISR. This does mean, however, that if a buggy routine forgets to reset the interrupt line after agreeing to deal with the interrupt, then the machine may hang in a loop of constant interrupts.</p></dd>
<dt><a name="id46576904">LFS</a></dt>
<dd><p>Large File Support, specifically files larger than 2Gb on 32-bit systems.</p></dd>
<dt><a name="id46576913">LFU</a></dt>
<dd><p>Least Frequently Used, another MM technique. The tension between recency of access and frequency of access of a an area of memory is one of the crucial parts of any memory management system.</p></dd>
<dt><a name="id46576923">libc</a></dt>
<dd><p>The standard C libraries. Remember that the kernel build makes no use of libc !</p></dd>
<dt><a name="id46576932">LIP</a></dt>
<dd><p>Loop Initialization Primitive, related to target IDs on SCSI busses.</p></dd>
<dt><a name="id46576941">livelock</a></dt>
<dd><p>When tasks are fighting for an exclusive resource, but are also ready to run. For example both tasks may be in a loop checking for a resource's availability.</p></dd>
<dt><a name="id46576951">lkml</a></dt>
<dd><p>The Linux-Kernel Mailing List. See <a href="http://www.tux.org/lkml/" target="_top">the FAQ</a> for details.</p></dd>
<dt><a name="id46576961">local APIC</a></dt>
<dd><p>On-chip interrupt controller provided on P6 and above Intel CPUs. Linux uses the timer interrupt register if a local APIC is available to provide its timer interrupt (is this true ?). The local APIC is part of a replacement for the old-style 8259 PIC, and receives external interrupts through an IO-APIC if there is one.</p></dd>
<dt><a name="id46576980">loopback device</a></dt>
<dd><p>The fake net device representing the local host net interface, lo. This can also refer to file loopback mounts.</p></dd>
<dt><a name="id46576988">loopback mount</a></dt>
<dd><p>There are two types of mount called loopback mounting. First is the file loopback mount, where a single file on a filesystem itself containing a filesystem is mounted (useful in constructing ISO9660 images for one). The other type, which is possible in 2.4, is &quot;true&quot; loopback mount, where you can do something like mount -t bind /safebin /chrootjail/bin.</p></dd>
<dt><a name="id46576998">LRU</a></dt>
<dd><p>As per the CS literature, Least Recently Used. A selection algorithm where a list is kept, ordered by last usage of each element. Often used in page replacement algorithms. Also Most Recently Used and LFU.</p></dd>
<dt><a name="id46577008">LUN blacklist</a></dt>
<dd><p>This is a blacklist of SCSI devices that do not properly handle probes with a Logical UNit number other than zero. Some mischievous devices respond to all LUNs, while others can hang with a LUN more than zero. LUNs are used in CD changers amongst other devices.</p></dd>
<dt><a name="id46577019">LVM</a></dt>
<dd><p>Logical Volume Manager. This allows several physical partitions to be represented as a single block device, amongst other things.</p></dd>
<dt><a name="id46577028">major fault</a></dt>
<dd><p>A major page fault occurs when an attempt to access a page not currently present in physical memory was made. The page must be swapped in to physical memory by the fault fixup code.</p></dd>
<dt><a name="id46577038">mb</a></dt>
<dd><p>Memory barrier; ensures on SMP systems that each CPU's view of memory is the same, i.e. enforces order. rmb() ensures reads are done in order, and wmb() ensures writes are done in order. Placing a barrier after some code basically makes sure that all previous memory reads or writes are done (as CPUs can re-order usually to increase performance). (FIXME: this needs to be more clear).</p></dd>
<dt><a name="id46577050">medium-often race</a></dt>
<dd><p>A race condition scenario. FIXME</p></dd>
<dt><a name="id46577058">memory rusting</a></dt>
<dd><p>Name for problems with mm code in v2.1, where pages got rusted and stuck in memory when they should really have been swapped out. Was a problem on small-memory machines. Now fixed (right ?)</p></dd>
<dt><a name="id46577068">MOESI</a></dt>
<dd>
<p>The name for a superset of cache coherency protocols. There are five possible states for a cacheline to be in:</p>
<div class="itemizedlist"><ul>
<li><p>
<a name="id46577080"></a>Modified: The data in the cacheline has been changed.</p></li>
<li><p>
<a name="id46577085"></a>Owned: The cache owner has exclusive rights to the contents of this data.</p></li>
<li><p>
<a name="id46577090"></a>Exclusive: The cacheline is not present on any other caches.</p></li>
<li><p>
<a name="id46577095"></a>Shared: The cacheline is shared with another cache, but does not need writing back to memory.</p></li>
<li><p>
<a name="id46577100"></a>Invalid: The cacheline is invalid and does not contain useful data.</p></li>
</ul></div>
<p>This protocol is described in more detail in the Schimmel book.</p>
</dd>
<dt><a name="id46577106">metadata</a></dt>
<dd><p>Information about a file, such as permissions, in contrast to the actual data in the file.</p></dd>
<dt><a name="id46577115">minor fault</a></dt>
<dd><p>A minor page fault occurs when an attempt to access a page present in physical memory, but without the correct permissions. An example is the first write to a second reference to a shared page, when the kernel must perform the copy-on-write and allow the task to update the copied page.</p></dd>
<dt><a name="id46577126">MMIO</a></dt>
<dd><p>Memory-mapped I/O, that is I/O memory (memory on hardware devices) accessible through a memory mapping. Also known as an I/O region.</p></dd>
<dt><a name="id46577135">monotonic</a></dt>
<dd><p>Technical term, meaning very roughly &quot;new data doesn't affect existing data&quot;. Used to mean a wide range of different things. For example, a monotonic clock is one which never gives a time prior to the time given previously (that is, sequential reads of the clock always increase).</p></dd>
<dt><a name="id46577146">MSR</a></dt>
<dd><p>Model-Specific Register. For the x86 platform, registers that are not guaranteed as part of the Intel Architecture (i.e. could be not present in future CPU models).</p></dd>
<dt><a name="id46577156">MSS</a></dt>
<dd><p>The Maximum Segment Size is the largest quantity of data that can be transmitted at one time over a net interface.</p></dd>
<dt><a name="id46577165">mtrr</a></dt>
<dd><p>Memory Type Range Registers.FIXME: explain what they do.</p></dd>
<dt><a name="id46577174">MTU</a></dt>
<dd><p>The Maximum Transmission Unit is a parameter that determines the largest datagram than can be transmitted by an IP interface without it needing to be broken down into smaller units. Typical values are 1500 bytes for an ethernet interface, or 576 bytes for a SLIP interface.</p></dd>
<dt><a name="id46577185">MTU discovery</a></dt>
<dd><p>The process of discovering the MTU of a remote site that can be used without causing expensive fragmentation. See DF.</p></dd>
<dt><a name="id46577194">n/w</a></dt>
<dd><p>Used occasionally for &quot;network&quot;.</p></dd>
<dt><a name="id46577202">Nagle's Algorithm</a></dt>
<dd><p>TCP algorithm for reducing network traffic in a connection. The local machine will accumulate outgoing data into packets until receiving a packet from the machine, and then the packets are sent. This way small amounts of outgoing data are amalgamated into the packet's larger payloads. Setting the TCP option NODELAY disables this behaviour. FIXME</p></dd>
<dt><a name="id46577214">nbd</a></dt>
<dd><p>Network Block Device - presents a local block device to a remote device.</p></dd>
<dt><a name="id46577223">negative entry</a></dt>
<dd><p>Meaning an error return rather than the expected entry from some vector or cache. A negative dentry is used when an NFS client tries to operate on a stale file, and with other situations. Without the negative dentry, a lookup is done on each request. This would allow a DoS attack by stealing CPU time doing lookups which will fail. So the dentry is kept around to provide a near-immediate &quot;stale file&quot; response to the client. See fs/dcache.c:d_delete(). Apparently positive dentries are not allowed to become negative. A negative dentry is one with a NULL d_inode field.</p></dd>
<dt><a name="id46577236">NMI</a></dt>
<dd><p>Non-maskable interrupt - highest-priority interrupt that can even interrupt standard h/w interrupt ISRs. The NMI watchdog is a kernel facility, running off NMIs, which checks CPUs for recent activity (in the last five minutes), to detect permanently stalled CPUs. NMIs are also delivered by motherboards in the case of serious hardware problems (like bad RAM).</p></dd>
<dt><a name="id46577248">nopage</a></dt>
<dd><p>A routine executed when a virtual address has been accessed when the page is for some reason not available in real memory. An example would be a swapped out page, hence the nopage operation would need to bring the page into real memory from the swap file.</p></dd>
<dt><a name="id46577259">nr_</a></dt>
<dd><p>&quot;Number of&quot;, e.g. nr_free_pages(). Preferred to the &quot;no_&quot; form as it's not ambiguous with the negative case (compare no_free_pages()).*</p></dd>
<dt><a name="id46577268">ntoh</a></dt>
<dd><p>Possibly byte-swapping conversion from network-endian to host-endian format. The network is big-endian.</p></dd>
<dt><a name="id46577277">NUMA</a></dt>
<dd><p>Non-Uniform Memory Architecture. Usually on an SMP system, all memory beyond the caches costs an equal amount to reach for each CPU. In NUMA systems, some memory can be accessed more quickly than other parts. Later kernels have some NUMA support for preferring to use memory &quot;nearer&quot; to the CPU, rather than higher-latency distant memory. See Documentation/vm/numa for details.</p></dd>
<dt><a name="id46577289">NVidia</a></dt>
<dd><p>A graphics card manufacturer that produce proprietary, non-open-source/binary kernel module drivers. Complaints about this module go to NVidia; such complaints are not welcome on linux-kernel. Also check #nvidia on irc.openprojects.net.</p></dd>
<dt><a name="id46577300">O()</a></dt>
<dd><p>Notation from Computer Science literature for complexity of algorithms. An O(1) algorithm takes constant time; an O(n) algorithm takes time proportional to N, the number of data, and so on. Also used for space complexity, the number of memory &quot;units&quot; used in the algorithm.</p></dd>
<dt><a name="id46577310">OHCI</a></dt>
<dd><p>Compaq standard for USB controllers.</p></dd>
<dt><a name="id46577319">one-hand algorithm</a></dt>
<dd><p>VM algorithm. A one-handed clock algorithm has one &quot;clock hand&quot; sweeping through pages, performing ageing and other activities.</p></dd>
<dt><a name="id46577328">oob</a></dt>
<dd><p>In networking Out-Of-Band data. FIXME</p></dd>
<dt><a name="id46577337">oops</a></dt>
<dd><p>An oops is generated on some kernel errors. This may be due to kernel bugs or faulty hardware (especially bad RAM). Often the kernel can continue to operate mostly correctly after an oops. More serious or potentially dangerous errors can cause a kernel panic (the O/S freezes). This is sometimes done to protect a filesystem from incurring further harm. An oops report will appear in the kernel logs, but is only useful to developers after decoding it with ksymoops (see Documentation/oops-tracing.txt). Note also that klogd can corrupt oops reports by incorrectly decoding it automatically. It is recommended to pass the -x option to klogd on startup to prevent this from happening. The plural form is oopsen.</p></dd>
<dt><a name="id46577352">out-of-order execution</a></dt>
<dd><p>Some processors (such as Intel Pentium Pro and above) can decode and execute more than one instruction at a time in parallel. This means a sequence of instructions is not necessarily the order in which those instructions are completed. See mb().</p></dd>
<dt><a name="id46577362">PAE36</a></dt>
<dd><p>Physical Address Extension - Intel's 36-bit physical address extensions for highmem.</p></dd>
<dt><a name="id46577371">page ageing</a></dt>
<dd><p>Marking a page as &quot;old&quot; in some way, that is, it hasn't been used for some time. Old pages are preferred for swapping out (although this is a simplification of the page swap selection algorithm), and are aged by kernel threads via a clock algorithm. Confusingly, page-&gt;age==0 indicates an infinitely old page (FIXME: true ?). The pte's are also aged for selection for flushing from the page table to the page or swap cache.</p></dd>
<dt><a name="id46577383">page cache</a></dt>
<dd><p>The page cache caches pages mapped from files (e.g. mapping in an executable image).</p></dd>
<dt><a name="id46577392">page colouring</a></dt>
<dd><p>A system to ensure that virtually-contiguous pages are not mapped to the same cache lines, improving performance. FreeBSD does this, but Linux, after some discussion, doesn't (yet).</p></dd>
<dt><a name="id46577402">page stealer</a></dt>
<dd><p>A task which steals from a process's vm, taking pages for itself. An example is kswapd, which runs through the pages of the system swapping out pages to keep freepages.min number of free pages.</p></dd>
<dt><a name="id46577412">pessimal</a></dt>
<dd><p>By analogy with optimal, the worst situation possible in some context.</p></dd>
<dt><a name="id46577421">PFF</a></dt>
<dd><p>FIXME</p></dd>
<dt><a name="id46577429">pgd</a></dt>
<dd><p>Page Global Directory, or the abstracted top level of the multi-level page tables. See pmd, pte. On x86, there are only two real levels of page tables; this fact is abstracted away by macros in the source. Each level of page table deals with different sizes of memory. For example, this global directory may deal with areas 4Mb in size. Each entry will be a pointer to a lower table of a smaller-sized directory. On x86, the next level (middle) is non present in hardware, and is folded in to the pgd in the kernel code. The bottom level deals in pages directly (PAGE_SIZE). So the pgd is a directory of page tables. Code which traverses this structure (such as the bttv driver) is said to walk the page tables.</p></dd>
<dt><a name="id46577444">PGE</a></dt>
<dd><p>FIXME</p></dd>
<dt><a name="id46577452">PIC</a></dt>
<dd><p>Programmable Interrupt Controller. See 8259 PIC, local APIC, IO-APIC.</p></dd>
<dt><a name="id46577461">PIO</a></dt>
<dd><p>The old-fashioned transfer protocol for devices on an IDE bus. Now mostly used is DMA, and standards like UDMA.</p></dd>
<dt><a name="id46577470">pinning</a></dt>
<dd><p>A pinned page cannot be swapped out of main memory.</p></dd>
<dt><a name="id46577479">pmd</a></dt>
<dd><p>Page Middle Directory. The middle level of page tables.</p></dd>
<dt><a name="id46577488">poisoning</a></dt>
<dd><p>Used in the slab cache for debugging purposes. Slabs are filled with a special value after they have been freed in order to catch double frees.</p></dd>
<dt><a name="id46577497">POSIX</a></dt>
<dd><p>A standard specifying semantics and interfaces for a UNIX-like kernel interface, along with standards for user-space facilities. There is a core POSIX definition which must be supported by all POSIX-conforming OSes, and several optional standards for specific facilities; so you may see references to &quot;POSIX shm&quot; or &quot;POSIX real-time signals&quot;.</p></dd>
<dt><a name="id46577509">PPPoE</a></dt>
<dd><p>PPP (point-to-point protocol, often used in modem up-links) running over Ethernet.</p></dd>
<dt><a name="id46577518">pre-emption</a></dt>
<dd>
<p>Involuntary switching of a CPU from one task to another. User-space is pre-empted by interrupts, which can then either return to the process, or schedule another process (a process switch will also occur when the process &quot;voluntarily&quot; gives up the CPU by e.g. waiting for a disk block in kernel mode).</p>
<p>Kernel mode tasks are never pre-empted (except by interrupts) - they are guaranteed use of the CPU until they sleep or yield the CPU. Some kernel code runs with interrupts disabled, meaning nothing except an NMI can interrupt the execution of the code.</p>
</dd>
<dt><a name="id46577534">pre-zeroing</a></dt>
<dd><p>Many pages (such as those for a process's BSS segment) need to be zeroed when accessed. As the kernel only takes the page on the page fault for these areas, it is possible to pre-zero some amount of pages before the page faults occur. FreeBSD does this, and there has been some inconclusive talk of including this feature in Linux. See demand zero.</p></dd>
<dt><a name="id46577545">printk</a></dt>
<dd><p> Obviously, the equivalent of printf for kernel code (remember, you can't use libc functions in the kernel). Can be called from interrupt context (although it does take the console spinlock) but floating-point cannot be used, as throughout the kernel.</p></dd>
<dt><a name="id46577556">priority inheritance</a></dt>
<dd><p>See priority inversion.</p></dd>
<dt><a name="id46577564">priority inversion</a></dt>
<dd><p>A situation where a low-priority task holds a resource which a higher-priority task is waiting for. This can occur with tasks scheduled with SCHED_OTHER or SCHED_IDLE, where a task with a higher scheduling priority will always be scheduled before in preference. This leads to deadlock as the low-priority task cannot be scheduled in order to release the lock, and the high-priority task can't continue without the lock on the resource. Priority inheritance is a putative solution, where the low-priority task temporarily takes on the priority of the other task, enabling its scheduling and release of the lock. However this approach can itself lead to deadlock (FIXME: is this really true ?).</p></dd>
<dt><a name="id46577579">processor affinity</a></dt>
<dd><p>Some OS's have system calls for binding a process to a particular CPU. The kernel ensures that when the process is re-scheduled it will be run on that processor. Linux currently doesn't support this and its relative merits are debatable.</p></dd>
<dt><a name="id46577589">processor ordering</a></dt>
<dd><p>The ordering of memory read and writes as seen from the CPU's point of view.</p></dd>
<dt><a name="id46577598">process context</a></dt>
<dd><p>Code executing in the kernel on behalf of a user process (from a syscall), is said to have a process context. Code not in a process context is not allowed to sleep or wait (see interrupt context).</p></dd>
<dt><a name="id46577608">process group</a></dt>
<dd><p>A set of user processes sharing the same group pid. One of these processes will be the group leader (same pid as pgid).</p></dd>
<dt><a name="id46577618">process suspension</a></dt>
<dd><p>When a VM is capable of completely suspending processes for a while. Also known as process swapping.</p></dd>
<dt><a name="id46577627">promiscuous</a></dt>
<dd><p>Of a network device, sucks all packets regardless of destination.</p></dd>
<dt><a name="id46577635">pte</a></dt>
<dd><p>Page Table Entry, or a value containing the physical address of a page along with associated bits indicating, for example, that the entry is valid and the related page is present in real memory.</p></dd>
<dt><a name="id46577645">put</a></dt>
<dd><p>In the kernel, means &quot;drop a reference to&quot;. This indicates that whatever task was using the object previously is no longer interested. This may just decrement a usage count, or perform a more complicated reaping routine.</p></dd>
<dt><a name="id46577656">QOS</a></dt>
<dd><p>Quality of Service.</p></dd>
<dt><a name="id46577664">race condition</a></dt>
<dd><p>Generally, where the ordering of events can affect the outcome of a situation. These bugs are caused by incomplete mutual exclusion, so a task or interrupt can come in and change something vital under the feet of another task. They are notoriously hard to debug as they are often marginal (often only occur in pathological==&quot;very unlikely&quot; situations).</p></dd>
<dt><a name="id46577676">RAID</a></dt>
<dd><p>Redundant Array of Independent/Inexpensive Disks. See the standard literature.</p></dd>
<dt><a name="id46577684">RAS</a></dt>
<dd><p>Reliability, Availability &amp; Serviceability.</p></dd>
<dt><a name="id46577693">rate limit</a></dt>
<dd><p>To avoid DoS attacks, some facilities have upper limits on how often they can trigger. Most trite example is logging.</p></dd>
<dt><a name="id46577702">raw I/O</a></dt>
<dd><p>I/O that does not go through the caches that Linux provides as standard to all block devices. This feature can be useful to database systems, where the database back-end has a better idea of the data access pattern than the kernel can, hence increasing performance.</p></dd>
<dt><a name="id46577713">read-ahead</a></dt>
<dd><p>Where I/O is performed before strictly required in an attempt to improve performance. This is performed by the Linux kernel, and often by hardware as well.</p></dd>
<dt><a name="id46577723">Readiness Event Queues</a></dt>
<dd><p>See completion ports.</p></dd>
<dt><a name="id46577731">red zone</a></dt>
<dd><p>Adding protection (e.g. read or write) to kernel pages, for use in detecting stack overflow and other situations. This often works by adding a guard area at the end of each buffer in the slab allocator, which is checked to make sure it hasn't been overwritten.</p></dd>
<dt><a name="id46577742">register spilling</a></dt>
<dd><p>FIXME</p></dd>
<dt><a name="id46577750">retired</a></dt>
<dd><p>On out-of-order processors, a retired instruction is one that has been executed and completed.</p></dd>
<dt><a name="id46577759">ring 0</a></dt>
<dd><p>ring 0 is the protection level provided by x86 hardware for kernel mode. Ring 3 is used in Linux for user mode, and rings 1 and 2 are unused. Ring transition to a higher protection level is only possible through gates. Interrupt gates are set up for transitions due to interrupts, and call gates are used for system calls.</p></dd>
<dt><a name="id46577770">ring buffer</a></dt>
<dd><p>A buffer of data which is of fixed size; when it fills, further data is placed back at the start of the buffer, overwriting the old data, in a &quot;ring&quot;. Commonly used in device drivers.</p></dd>
<dt><a name="id46577780">root squashing</a></dt>
<dd><p>An NFS option whereby any actions performed by a remote client's root account are actually attempted by the user &quot;nobody&quot; on the server.</p></dd>
<dt><a name="id46577790">RX</a></dt>
<dd><p>Common abbreviation used in net code for &quot;receive&quot;.</p></dd>
<dt><a name="id46577798">scatter-gather</a></dt>
<dd><p>An I/O mechanism, whereby devices can write to memory at several physically non-contiguous addresses (scatter), and compose reads from physically non-contiguous addresses in memory (gather).</p></dd>
<dt><a name="id46577808">semaphore</a></dt>
<dd><p>As per the literature, a mutual exclusion or resource management method where tasks sleep waiting for a semaphore to be granted to them. Later versions of the Linux kernel also provide a more complicated type, the read-write semaphore, which allows a task to specify its intentions with regard to the resource. Hence several readers are allowed for the resource, but a writer will have mutual exclusion.</p></dd>
<dt><a name="id46577820">session</a></dt>
<dd><p>Sessions are related to terminal handling. Sessions can have a controlling terminal; by becoming a session group leader, a daemon process can detach itself from any controlling terminal. A session group is a set of processes created by the session leader. FIXME</p></dd>
<dt><a name="id46577831">set_fs</a></dt>
<dd><p>The set_fs() facility enables the copy_*_user routines to access kernel (KERNEL_DS) or user (KERNEL_FS) memory. This is required in kernel code that uses functions that expect to copy data from user-space, so that the correct segment is used (i.e. copying from kernel memory rather than user space memory).</p></dd>
<dt><a name="id46577842">shm</a></dt>
<dd><p>Shared memory. This is memory accessible through more than one processes' virtual address map. There are standardised shm interfaces derived from System V, as well as POSIX.</p></dd>
<dt><a name="id46577852">silly delete</a></dt>
<dd><p>Silly-deleting in NFS is used when somebody tries to delete a file that is held open by some other process. The deletion is delayed, and the file is instead renamed to something along the lines of .nfsxxxxxxxxx. The last process to close the file will then attempt to delete it.</p></dd>
<dt><a name="id46577863">slab allocator</a></dt>
<dd><p>Cache-based kernel memory allocation scheme used by kmalloc(). Bonwick's paper can be found at ftp://ftp.bitmover.com/pub/slab.ps. When actually requiring new pages, __get_free_pages() is called which uses alloc_pages(), with the standard buddy allocator.</p></dd>
<dt><a name="id46577873">softirq</a></dt>
<dd><p>Interrupts run on return to user space or after a hardware interrupt, and there is a fixed number available. See tasklet, bottom-half handler. These methods are usually used to run kernel code resulting from a hardware interrupt of some kind, where the necessary operations take too long to execute in hardirq context. A notable case is routines queuing on TIMER_BH which are executed depending on the hardware timer tick. These are different from DOS soft interrupts as they don't make use of hardware soft interrupt support (int instruction), although these types of soft interrupt are used in kernel code, for example kernel_thread().</p></dd>
<dt><a name="id46577888">SO_LINGER</a></dt>
<dd><p>FIXME</p></dd>
<dt><a name="id46577896">spinlock</a></dt>
<dd><p>A busy-wait method of ensuring mutual exclusion for a resource. Tasks waiting on a spin-lock sit in a busy loop until the spinlock becomes available. On a UP (single processor) system, spinlocks are not used and are optimised out of the kernel. There are also read-write spinlocks, where multiple readers are allowed, but only one writer. See Documentation/spinlocks.txt in the kernel source for details.</p></dd>
<dt><a name="id46577908">sti</a></dt>
<dd><p>See cli/sti.</p></dd>
<dt><a name="id46577916">superblock</a></dt>
<dd><p>An fs-specific data structure, stored on disk, that holds various bits of information about the fs on the disk, such as a pointer to the free blocks structure, the number of free inodes, etc. In the code, the inode manipulation routines are entered in super_operations vector of function pointers. Often abbreviated to sb.</p></dd>
<dt><a name="id46577927">SuS</a></dt>
<dd><p>The Single Unix Specification, a standard defined with the aim of standardisation of Unix-like OS semantics and APIs. There is also a second version of this standard, referred to as SuS v2.</p></dd>
<dt><a name="id46577937">SVR4</a></dt>
<dd><p>System V Release 4, as in the UNIX source that POSIX is mostly based on.</p></dd>
<dt><a name="id46577946">SYN cookies</a></dt>
<dd><p>Protection against TCP/IP SYN flooding DoS attack by storing state information about SYN packets from hosts. See ftp://koobera.math.uic.edu/syncookies.html.</p></dd>
<dt><a name="id46577956">system calls</a></dt>
<dd><p>The method by which a user process requests facilities provided by the kernel. Examples are wait4(2), open(2), and sched_setscheduler(2). By an architecture-specific method, the kernel is executed on behalf of the process in kernel mode at the entry point of the system call. Generally there is a convention in the source that syscall entry points are prefixed with sys_, for example, the entry point to open(2) is the function sys_open in the file fs/open.c. Code executing in kernel mode (that is, with access to the kernel's memory) from a syscall entry point is said to have a process context. On x86, all system calls executed from user mode use int 0x80 and came through the syscall call gate in arch/i386/kernel/entry.S.</p></dd>
<dt><a name="id46577978">tail merging</a></dt>
<dd><p>Tail merging is a technique which collects tails of multiple files together in one block to save space, reducing internal fragmentation, especially at larger block sizes.</p></dd>
<dt><a name="id46577988">task</a></dt>
<dd><p>The kernel abstraction for every user process, user thread, and kernel thread. All of these are handled as tasks in the kernel. Every task is described by its task_struct. User processes/threads have an associated user_struct. When in process context, the process's task_struct is accessible through the routine get_current, which does assembly magic to access the struct, which is stored at the bottom of the kernel stack. When running in kernel mode without process context, the struct at the bottom of the kernel stack refers to the idle task.</p></dd>
<dt><a name="id46578001">tasklet</a></dt>
<dd><p>&quot;Software interrupt&quot; routines running when the software interrupt is received at a return to user space or after a hardware interrupt. They do not run concurrently on multiple CPUs, but are dynamically allocatable. See softirq and bottom-half handler.</p></dd>
<dt><a name="id46578012">task queue</a></dt>
<dd><p>A linked list of processes or threads. Tasks, for example, can queue on bottom-half handlers waiting to be executed. See wait queue.</p></dd>
<dt><a name="id46578021">TC</a></dt>
<dd><p>FIXME</p></dd>
<dt><a name="id46578029">TCQ</a></dt>
<dd><p>Tagged Command Queuing. This facility allows the kernel to send several asynchronous requests at once to a block device. The device can service the requests as it sees fit; the advantage being that the device can arrange the transfers as best suits the device hardware. TCQ works for both reads and writes.</p></dd>
<dt><a name="id46578041">thundering herd</a></dt>
<dd><p>Consider a set of tasks on a wait queue, waiting for some condition. When the event occurs, it is often the case that only some of the tasks has real work to do. Older kernels always woke up all tasks on the wait queue - this meant that each task immediately vied for scheduling - the &quot;thundering herd&quot;. More recent kernels have added the TASK_EXCLUSIVE flag to tasks in the wait queue. This ensures that one of the tasks with this flag set will be the only one to be woken up.</p></dd>
<dt><a name="id46578054">TLB flushing</a></dt>
<dd><p>Flagging part or all of a CPU's translation lookaside buffer (which is a virtual-address-indexed cache of physical addresses) as invalid. Depending on hardware, the whole TLB may be flushed at any one time, or just a part.</p></dd>
<dt><a name="id46578064">tmpfs</a></dt>
<dd><p>One of those cyclical lkml threads. O/S's such as Solaris have a &quot;tmpfs&quot; filesystem, providing a fs interface using main memory as storage. This differs from the usual ram disk in that it is swappable. The fs is often used for /tmp, which provides performance gains. Under Linux, ext2fs is already faster than Solaris' tmpfs, so no-one has ever implemented this.</p></dd>
<dt><a name="id46578076">trampoline</a></dt>
<dd><p>The process by which a compiler has special code to deal with code presented as data within a binary's segment, which is to be executed, amongst other scenarios. A short routine is called before the real procedure which sets up the stack environment correctly. This facility is used in languages such as Ada, and complicates provision of non-executable stack support at kernel level (useful for preventing simplistic buffer over-runs). FIXME </p></dd>
<dt><a name="id46578088">TSC</a></dt>
<dd><p>Time Stamp Counter, a very high resolution counter on the Intel platform.</p></dd>
<dt><a name="id46578097">two-hand algorithm</a></dt>
<dd><p>VM algorithm. A two-handed clock algorithm has two &quot;clock hands&quot; sweeping through pages, performing ageing and other activities. Imagine one hand ageing pages, whereas the later one decides to mark pages as unused.</p></dd>
<dt><a name="id46578107">TX</a></dt>
<dd><p>Common abbreviation used in net code for &quot;transmit&quot;.</p></dd>
<dt><a name="id46578116">UART</a></dt>
<dd><p>Universal Asynchronous Receiver/Transmitter. UARTs are hardware devices that convert byte-wide data streams in to serial (bit-wide) data streams.</p></dd>
<dt><a name="id46578125">UBC</a></dt>
<dd><p>Unified Buffer Cache - the combination of the buffer and page caches to use the same memory pool (disk I/O and VM use the same pool), and data I/O utilises the page cache.</p></dd>
<dt><a name="id46578135">UHCI</a></dt>
<dd><p>Intel standard for USB controllers.</p></dd>
<dt><a name="id46578144">union mount</a></dt>
<dd><p>Each mount structure is represented in the kernel by a dentry tree. Sharing of a tree allows union mount, where two separate mounts are accessible under one mount point.</p></dd>
<dt><a name="id46578153">uop</a></dt>
<dd><p>For micro-operation, or the basic set of CPU operations which are generated from machine code in microcode processors. Intel P6 processors and above have the facility for upgrading the microcode (stepping of the processor).</p></dd>
<dt><a name="id46578164">URB</a></dt>
<dd><p>USB Request Block, or the message struct for Universal Serial Bus.</p></dd>
<dt><a name="id46578172">user-mode port</a></dt>
<dd><p>A patched version of the kernel modified to run on top of user-space. This is intended to be used for testing, experimentation and debugging. See http://user-mode-linux.sf.net.</p></dd>
<dt><a name="id46578182">UTSL</a></dt>
<dd><p>Use The Source, Luke!</p></dd>
<dt><a name="id46578190">V4L</a></dt>
<dd><p>Video 4 Linux</p></dd>
<dt><a name="id46578199">versioned filesystem</a></dt>
<dd><p>A filesystem that tracks changes to files, for example by storing the entire previous file on a change in data.</p></dd>
<dt><a name="id46578208">VFS</a></dt>
<dd><p>VFS is the filesystem-independent in-kernel interface used to access each particular filesystem supported by Linux.</p></dd>
<dt><a name="id46578217">VLIW</a></dt>
<dd><p>Very Long Instruction Word, instruction sets with large-sized complex instructions encoded into one instruction.</p></dd>
<dt><a name="id46578227">vmalloc</a></dt>
<dd><p>Allocates a virtual address space. Can be slow for some purposes as it requires a TLB flush on all processors. Does not ensure physical address contiguity, but can allocate arbitrary sized areas. Also requires (along with related vfree()) the big kernel lock.</p></dd>
<dt><a name="id46578237">VMWare</a></dt>
<dd><p>Commercial virtual O/S software. If the modules won't compile for you, DO NOT complain to linux-kernel ! And see FreeMWare/Plex86.</p></dd>
<dt><a name="id46578247">volatile</a></dt>
<dd><p>From the C keyword. Used throughout the source and in discussion, signifying a variable or inline asm that cannot be optimised as usual by the compiler. This usually means the compiler shouldn't store the variable in a register, as another task can alter the value of the real memory contents at the time. For example, this is necessary with I/O address spaces, where the hardware device can fill up a buffer asynchronously to a reading task. Variables which are changed from both interrupts and other contexts are also volatile.</p></dd>
<dt><a name="id46578265">wait queue</a></dt>
<dd><p>A linked list of tasks (processes or threads) waiting on some specific condition. For example, a locked page may have a wait queue of tasks waiting for I/O on that page to complete (that is, !PageLocked(page)).</p></dd>
<dt><a name="id46578275">wall time</a></dt>
<dd><p>Real time, that is, the sort you would expect to find on a clock on your wall...</p></dd>
<dt><a name="id46578284">wandering logs</a></dt>
<dd><p>On journalling filesystems, the metadata must be logged. A wandering log system spreads log blocks throughout the filesystem for performance, rather than using a static log area on the disk.</p></dd>
<dt><a name="id46578294">warm cache</a></dt>
<dd><p>A cache whose contents are not invalid and are useful to the task to be run next. It is important to benchmark code in both cold-cache and warm-cache circumstances.</p></dd>
<dt><a name="id46578304">write bomb logic</a></dt>
<dd><p>Code to protect interactivity from being harmed by large writes. FIXME</p></dd>
<dt><a name="id46578312">write behind</a></dt>
<dd><p>A.K.A. delayed write, asynchronously writing after the write request was made.</p></dd>
<dt><a name="id46578321">WS</a></dt>
<dd><p>FIXME</p></dd>
<dt><a name="id46578329">XDR</a></dt>
<dd><p>External Data Representation, the marshalled form of RPC communications. XDR deals with sizing and endianness issues.</p></dd>
<dt><a name="id46578339">XIP</a></dt>
<dd><p>&quot;Execute in-place&quot;. For normal storage devices, executables are loaded into main memory before execution. For devices like a ram disk or flash system, it is possible to execute the program straight from the device, without duplication.</p></dd>
<dt><a name="id46578349">zero-copy</a></dt>
<dd><p>Networking where no data is copied to/from userspace during network transmit or receive. This is often touted as a universally good thing, but in fact it is a trade-off between the cost of the copy, and the cost of setting up page tables etc. such that user-space can read the data.</p></dd>
<dt><a name="id46578360">ZFOD</a></dt>
<dd><p>Zero-fill-on-demand, a page filled with zeros for which no space has yet been allocated.</p></dd>
<dt><a name="id46578369">zombie</a></dt>
<dd><p>A completed process whose parent has not waited for it. When a child exits, the return status must remain available to the parent, as it may later do a wait4(). A zombie holds its place in the process table until the parent waits for it.</p></dd>
<dt><a name="id46578380">zone</a></dt>
<dd><p>A particular area of free memory. Zoned allocators differentiate between intended uses, and are generally used to model different characteristics of the memory. For example, on the x86 there is only 16Mb of DMA-able memory; the zoned allocator will try to save DMA pages for processes specifically requesting ZONE_DMA memory. There are currently three zone types: ZONE_DMA, ZONE_NORMAL, and ZONE_HIGHMEM (see highmem).</p></dd>
</dl>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a href="indexs16.html">Prev</a><EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Home</a></td>
<td width="40%" align="right"><EFBFBD><a href="indexs17.html#id46575701">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left">To Do<44></td>
<td width="20%" align="center"><a href="index.html">Up</a></td>
<td width="40%" align="right"><EFBFBD>Glossary</td>
</tr>
</table>
</div>
</body>
</html>

47
docs/kernelhacking-HOWTO/indexs18.html Normal file
View File

@@ -0,0 +1,47 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<title>References &amp; Acknowledgments</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.40">
<link rel="home" href="index.html" title="Kernel Hacking HOWTO">
<link rel="up" href="index.html" title="Kernel Hacking HOWTO">
<link rel="previous" href="indexs17.html#id46575701" title="Glossary">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">References &amp; Acknowledgments</th></tr>
<tr>
<td width="20%" align="left">
<a href="indexs17.html#id46575701">Prev</a><EFBFBD></td>
<th width="60%" align="center"><EFBFBD></th>
<td width="20%" align="right"><EFBFBD></td>
</tr>
</table>
<hr>
</div>
<div class="sect1">
<a name="ref"></a><div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="ref"></a>References &amp; Acknowledgments</h2></div></div>
<div class="itemizedlist"><ul><li><p>
<a name="id46578397"></a>Glossary originally by John Levon (and others), taken from <a href="http://www.kernelnewbies.org" target="_top">the kernelnewbies glossary</a>. Used by permission.</p></li></ul></div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a href="indexs17.html#id46575701">Prev</a><EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Home</a></td>
<td width="40%" align="right"><EFBFBD></td>
</tr>
<tr>
<td width="40%" align="left">Glossary<EFBFBD></td>
<td width="20%" align="center"><a href="index.html">Up</a></td>
<td width="40%" align="right"><EFBFBD></td>
</tr>
</table>
</div>
</body>
</html>