@<<INCLUDE ../template/head.inc@!>>
@<<INCLUDE ../template/nav.inc@!>>
@<<DEF google="8963309302"@!>>
@<<DEF google-search="6039882207"@!>>
@<<DEF title=LKDDb: Linux Kernel Driver DataBase@!>>
@<<ME /lkddb/@!>>

<div class="title">
  <h1>LKDDb: Linux Kernel Driver DataBase</h1>
  <h2>what Linux drivers are for me?</h2>
</div>

<div class="main">

<script type="text/javascript"
  src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>


<h2>About LKDDb</h2>

<p>LKDDb is an attempt to build a comprensive database of hardware and
protocols know by Linux kernels.
The driver database includes numeric identifiers of
hardware, the kernel configuration menu needed to build the driver and
the driver filename.
The database is build automagically from kernel sources,
so it is very easy to have always the database updated.</p>

<p>There exists two versions: text based database, to be processed
automatically (see <code>lkddb.list</code> below),
and the
<a href="web-lkddb/">web LKDDb</a> version, which includes
also text and hardware strings from kernel and other databases.</p>


<h2>Automagical Kernel Configuration</h2>

<p>The automatic kernel configuration is an obvious application of the driver
database. It combines an hardware detection, that could be easy performed
checking buses in <code>/sys/bus</code>.</p>

<p>The Automagical Kernel Configuration has an own
<a href="/autokernconf/">AutoKernConf project page</a>.</p>


<h2>News</h2>

<p>Important news about the project:</p>
<ul>
  <li>2007-11-22: API changes. Now I use <code>lkddb.list</code> with
	different <a href="format.html">format</a>.</li>
  <li>2007-11-13: <a href="web-lkddb/">web lkddb</a> of a browsable
	and human readable version of the database</li>
  <li>2007-11-08: code clean-up, better detections, finished the format page.
  	Renamed the database to <code>lkddb.data</code></li>
  <li>2007-11-01: add module name, configuration as virtual data</li>
  <li>2007-10-29: created this page</li>
  <li>2007-10-28: annonced the project in the
    <a name="lkml" id="lkml" href="http://lkml.org/lkml/2007/10/28/101">lkml</a>
    </li>
</ul>

<p>Latest changes:</p>
<ul>
  <li>2007-11-22: add 'zorro' support.</li>
  <li>2007-11-12: better (general) regex, so huge increment
    (three times) of USB devices (and also some more PCI devices).</li>
  <li>2007-11-12: add TURBOchannel (tc) detection</li>
</ul>


<h2>Getting the database</h2>

<p>The database is a text file, which contains:
sub system, sub system specific hardware data,
kernel configurations and kernel driver file that contain such probe.
Usually the system specific hardware data is in form of mask,
and list only fields that are really checked by the kernel.
Detailed information are available in
<a href="format.html">lkddb format</a> page.</p>

<p>The latest versions is in file <code>lkddb.list</code> on
<a href="/sources/lkddb/">sources/lkddb/</a> directory.</p>

<p>Actually the LKDDb contains probes for the subsytems:</p>

<ul>
  <li>PCI bus devices</li>
  <li>USB bus devices</li>
  <li>IEEE1394 devices</li>
  <li>s390 CCW devices</li>
  <li>s390 AP bus devices</li>
  <li>ACPI devices</li>
  <li>Plug'N Play (PnP) devices (on ISA bus)</li>
  <li>Plug'N Play (PnP) devices (on ISA bus) alternate kernel detection</li>
  <li>SERIO</li>
  <li>OF</li>
  <li>VIO</li>
  <li>PCMCIA bus devices</li>
  <li>input</li>
  <li>EISA bus devices</li>
  <li>parisc specific devices</li>
  <li>SDIO</li>
  <li>SBB (Sonics Silicon Backplane) bus devices</li>
  <li>virtio (virtual I/O)</li>
  <li>TC (TURBOchannel)</li>
  <li>Zorro</li>
  <li>I2C</li>
  <li>Filesystem (only the names, no harddisk detection)</li>
  <li>modules (virtual probes): map module name with configuration</li>
</ul>

<p>There also some <a href="statistics.html">statistics</a> on total probes, and
probes per subsystem.</p>


<h2>Getting the lkddb.list generator</h2>

<p>The program (<code>build-lkddb.py</code> and four short modules:
<code>devicetables.py</code> (definition of probes),
<code>utils.py</code> (main support routines),
<code>kbuildparser.py</code> (support for configuration and makefiles),
<code>srcparser.py</code> (expand macro))
is a python script, distributed with the GNU GPL v2.
It was designed with a lot of euristic on how the hardware is coded
in Linux kernel, but it should be pretty accurate, and designed to
be quite fast (it take nearly 2 minutes, with warm cache on my
computer).
Additionally, the program <code>web-lkddb-gen.py</code>
will build the online version of lkddb.</p>

<p>The sources are placed in the
<a href="/sources/lkddb-sources/">sources/lkddb-sources/</a> directory.</p>

<h3>Usage:</h3>

<p><code>./build-lkddb.py <em>/home/cate/kernel/6,v2.6/linux-2.6/</em></code></p>

<p>The first argument is the top directory of kernel source tree.
Eventually you can restrict the subdirectories to be parsed, adding
as extra arguments these directories (Note: anyway it will parse the whole
include/ directories).</p>

<p>The program will write the database to <code>lkddb.list</code>, and a
lot of diagnostic message to the console (which I use to improve
euristic detection).</p>


<h2>Slides</h2>

<p>I've done a presentation at a Open Source Jam in Google Zurich:</p>

<iframe src='http://docs.google.com/EmbedSlideshow?docid=dcq62xvj_0t2vqc5rk' frameborder='0' width='410' height='342'></iframe>


<h2>History</h2>

<p>A long time ago (in 2000), to remove some <em>Empire</em> code, the
former kbuild team designed a new way to build and configure the kernel.
The third (and minor) task was to add an <em>autoconfig</em> target to
the build system.  I took the autoconfiguration part. Then was flames,
flames and flame (maybe someone remember about CML2 and the
<em>Aunt Tillie</em>. So the new <em>make</em> and the new
<em>CML2</em> was rejected, and because my part was dependent to the
other two sub project (and to have a simpler life), I hibernate the
project.</p>

<p>In late 2007, I restored the project, rewriting and publishing
some part that was never finished.  Atually I works more on
the driver database, because I find that automatic configuration is
a more problematic field: what should be the target configuration?
In direction of perfection, so minimal, or in direction of
optimal, so removing only surelly unneeded drivers?.</p>

<p>So I split the project in two, allowing external programs
to use the database.</p>


<h2>Contact</h2>

<p>You can contact me using <code>cate</code> (at) <code>cateee.net</code></p>

<p></p>

</div>
@<<INCLUDE ../template/foot.inc@>>