[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Documentation/kernel/programming.list: 1.19 -> 1.29
以下のページの更新をしました。ツッコミをお願いします。
Documentation/kernel/programming.list: 1.19 -> 1.29
更新後の訳を
http://www.na.rim.or.jp/%7Ekano/tmp/Documentation/kernel/programming.list
http://www.na.rim.or.jp/%7Ekano/tmp/Documentation/kernel/programming.html
に置いてあります。対応する原文は、
http://cvsweb.netbsd.org/bsdweb.cgi/%7Echeckout%7E/htdocs/Documentation/kernel/Attic/programming.list?rev=1.29&content-type=text/plain
http://cvsweb.netbsd.org/bsdweb.cgi/%7Echeckout%7E/htdocs/Documentation/kernel/programming.html?rev=1.48&content-type=text/html
です。
火曜日までに異議がなければ、 commit します。
以下、訳と原文の差分です。
--- programming.list.orig Sat Sep 17 00:43:38 2005
+++ programming.list Sat Sep 17 01:42:10 2005
@@ -6,6 +6,7 @@
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED. -->
<meta http-equiv="Content-Type" content="text/html; charset=ISO-2022-JP">
<link rev="made" href="mailto:www@jp.NetBSD.org">
+<link rel="shortcut icon" href="/favicon.ico" type="image/x-icon">
<title>NetBSD Documentation: Kernel Programming FAQ</title>
</head>
<body bgcolor="#FFFFFF" text="#000000">
@@ -16,16 +17,19 @@
<h2>他の関連するリンク</h2>
<ul>
-<li><a href="scsidma.html">SCSI DMA はどのように動作するか</a> - Tohru Nishimura による
-<li><a href="lazyfpu.html">lazy FPU コンテキストスイッチはどのように動作するか</a> - Tohru
- Nishimura による
+<li> driver(9) - デバイスドライバーが利用する NetBSD の自動コンフィギュレーションのインターフェース
+<li> autoconf(9) - NetBSD の自動コンフィギュレーションフレームワークについての
+ 全般的な説明
+<li> config(9) - 自動コンフィギュレーションフレームワークの「デバイス定義」言語
<li> bus_dma(9) - NetBSD のバスとマシン独立な DMA フレームワーク、これに
関する<a href="bus_dma.ps">論文</a> (120k、ポストスクリプト)
<li> bus_space(9) - NetBSD のバススペースの操作のためのインターフェース
-
+<li><a href="scsidma.html">SCSI DMA はどのように動作するか</a> - Tohru Nishimura による
+<li><a href="lazyfpu.html">lazy FPU コンテキストスイッチはどのように動作するか</a> - Tohru
+ Nishimura による
<li><a href="/Documentation/kernel/converting-ethernet-drivers.html" origlink="converting-ethernet-drivers.html">
昔の BSD のイーサネットドライバーの NetBSD-1.2D 以降への移植</a>
-<li><a href="/Documentation/kernel/porting-freebsd-net.html" origlink="porting-freebsd-net.html">
+<li><a href="porting-freebsd-net.html">
FreeBSD のネットワークドライバーを NetBSD に移植するためのメモ</a>
</ul>
@@ -104,6 +108,64 @@
<li><CURRENTSRC>/sys/dev/ic/lance.c
- MI コアのドライバーのコード。
</ul>
+<p>
+<a href="#autoconf">autoconf の説明</a>もご覧ください。
+
+
+<ENTRY>autoconf この autoconf の素材は、どのように動作するのか?
+<p>
+autoconf の仕組みは、その動作方法を一度理解してしまえば非常に単純なものです。
+実行時にデバイスプローブツリーがどのように構築されて使われるのかについて、
+正確な詳細は無視したいのであれば、
+個々の「葉」のドライバーに関して必要なことは以下のとおりです。
+<ol>
+ <li> 各ドライバーは、 3 個の構成要素からなる構造体を規定します -
+ 構成要素は、そのプライベート構造体のサイズ、プローブ関数、アタッチ関数です。
+ これはコンパイルされて実行時に使われます - たとえば以下のようになります:
+<p>
+<pre>
+struct cfattach foo_baz_ca = {
+ sizeof(struct foo_baz_softc), foo_baz_match, foo_baz_attach
+};
+</pre>
+ <li> カーネル起動に際して、このデバイスをアタッチする時に、
+ autoconf のコードはデバイスのプローブルーチンを呼んで、
+ 親へのポインター (<tt>struct device *parent</tt>)・
+ アタッチタグ構造体へのポインター (<tt>void *aux</tt>)・
+ 適切な autoconf ノード (<tt>struct cfdata *cf</tt>) を渡します。
+ ドライバーは、呼ばれるべき場所かどうかを判断することになっています
+ (通常、ロケーションおよびコンフィギュレーション情報がアタッチタグによって渡されます)。
+ そこがしかるべき場所だった場合は、プローブルーチンは 1 を返すべきです。
+ もしデバイスがそこになければ、プローブルーチンは 0 を返す必要があります。
+ いずれの場合も、<b>いかなる状態も保持されてはいけません</b>。
+ <li> プローブが成功して戻ると、 autoconf は、デバイスの *_ca
+ で指定されたサイズのメモリー塊を割り当て、そのデバイスのアタッチルーチンを呼んで、
+ 親へのポインター (<tt>struct device *parent</tt>)・
+ 今割り当てたメモリーへのポインター(<tt>struct device *self</tt>)・
+ アタッチタグ構造体へのポインター (<tt>void *aux</tt>) を渡します。
+ ドライバーは、正確なポートとメモリーを見つけ出し、資源を割り当て、
+ これに応じてドライバー内の構造体を初期化することになっています。
+ ドライバーのインスタンスに固有な情報は、
+ 極力、ここで割り当てられたメモリーに保持すべきです。
+</ol>
+<p>
+例: PCI イーサネットドライバー 'baz' を考えましょう。
+カーネルコンフィグは以下のようになっています:
+<pre>
+pci* at mainbus?
+baz* at pci? dev ? function ?
+</pre>
+<p>
+実行時、 autoconf はマシンの pci バス上の物理デバイスすべてに対して
+繰り返し実行されます。各物理デバイスに対して、 autoconf は、
+pci バス上にあることがカーネルに設定されているすべてのデバイスの
+ドライバーのプローブルーチンを呼ぶことを繰り返します。
+いずれかのプローブルーチンがそのデバイスについて 1 を返すと、
+autoconf はこれを中止し、上述の 3) で説明した作業をおこないます。
+アタッチ関数が戻ると、 autoconf は次の物理デバイスの処理を続けます。
+<p>
+<a href="#adding_a_new_driver">カーネルに新しいドライバーを追加する</a>もご覧ください。
+
<ENTRY>adding_a_system_call システムコールを追加する
<tt>syscalls.master</tt> にエントリーを追加し、syscall スタブを
@@ -111,6 +173,17 @@
<CURRENTSRC>/usr/src/lib/libc/sys/Makefile.inc
</tt> の適当な場所に追加してください。
+<ENTRY>adding_a_sysctl sysctl を追加する
+<a href="http://mail-index.NetBSD.org/tech-kern/">tech-kern</a>
+メーリングリストに、この質問への答えが
+<a href="http://mail-index.NetBSD.org/tech-kern/2001/06/24/0000.html">投稿</a>
+されているので、そちらを参照してください。
+<p>
+
+なお、 NetBSD 1.6 とそれ以降では、ベンダー特有の項目用として、
+特別な "vendor" カテゴリーが予約されています。さらなる情報は
+sysctl(8) を参照してください。
+
<ENTRY>mmap_in_pseudo-device 仮想デバイスに mmap を実装する方法
あなたの作ったデバイスは、おそらくキャラクターデバイスでしょう。もし、
そうであれば、デバイスページャーを使っているはずです。(VM システムは、
@@ -209,7 +282,7 @@
</LIST>
-<a href="" origlink=""><em>NetBSD Documentation: Kernel</em> に戻る</a>
+<a href="./"><em>NetBSD ドキュメンテーション: カーネル</em> に戻る</a>
<hr>
<DOCLINK>
@@ -220,9 +293,9 @@
(連絡先 - <a href="http://www.NetBSD.org/cgi-bin/feedback.cgi">英語</a>,
<a href="mailto:www@jp.NetBSD.org">日本語:
www@jp.NetBSD.org</a>)<br>
- $NetBSD: programming.list,v 1.19 2001/03/16 14:50:45 dent Exp $<br>
+ $NetBSD: programming.list,v 1.29 2004/03/20 20:38:25 snj Exp $<br>
<!-- based on english translation: -->
- <!-- NetBSD: programming.list,v 1.19 2001/03/16 14:50:45 dent Exp -->
+ <!-- NetBSD: programming.list,v 1.29 2004/03/20 20:38:25 snj Exp -->
<a href="../../Misc/disclaimer.html">Copyright © 1994-2003
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.</a>
</small>
Index: programming.list
===================================================================
RCS file: /cvsroot/htdocs/Documentation/kernel/Attic/programming.list,v
retrieving revision 1.19
retrieving revision 1.29
diff -u -r1.19 -r1.29
--- programming.list 16 Mar 2001 14:50:45 -0000 1.19
+++ programming.list 20 Mar 2004 20:38:25 -0000 1.29
@@ -2,9 +2,10 @@
<html>
<head>
-<!-- Copyright (c) 1994-2001
+<!-- Copyright (c) 1994-2003
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED. -->
-<link rev="made" href="mailto:www@NetBSD.ORG">
+<link rev="made" href="mailto:www@NetBSD.org">
+<link rel="shortcut icon" href="/favicon.ico" type="image/x-icon">
<title>NetBSD Documentation: Kernel Programming FAQ</title>
</head>
<body bgcolor="#FFFFFF" text="#000000">
@@ -15,12 +16,16 @@
<h2>Other related links</h2>
<ul>
+<li> driver(9) - NetBSD autoconfiguration interface utilised by device drivers
+<li> autoconf(9) - General description on the NetBSD autoconfiguration
+ framework
+<li> config(9) - The autoconfiguration framework ``device definition'' language
+<li> bus_dma(9) - NetBSD's bus and machine independent DMA framework,
+ described in its own <a href="bus_dma.ps">paper</a> (120k, postscript)
+<li> bus_space(9) - NetBSD's bus space manipulation interface
<li><a href="scsidma.html">How SCSI DMA works</a> - by Tohru Nishimura
<li><a href="lazyfpu.html">How lazy FPU context switch works</a> - by Tohru
Nishimura
-<li> bus_dma(9) - NetBSD's bus and machine independent DMA framework,
- described in it's own <a href="bus_dma.ps">paper</a> (120k, postscript)
-<li> bus_space(9) - NetBSD's bus space manipulation interface
<li><a href="converting-ethernet-drivers.html">
Converting ancient BSD Ethernet drivers to NetBSD-1.2D and later</a>
<li><a href="porting-freebsd-net.html">
@@ -98,6 +103,64 @@
<li><CURRENTSRC>/sys/dev/ic/lance.c
- MI core driver code.
</ul>
+<p>
+See also <a href="#autoconf">the autoconf explanation</a>.
+
+
+<ENTRY>autoconf How does all this autoconf stuff work?
+<p>
+The autoconf machinery is quite simple once you figure out the way
+it works. If you want to ignore the exact details of how the device
+probe tree is built and walked on runtime, the bits needed for
+each individual "leaf" driver are like this:
+<ol>
+ <li> each driver specifies a structure holding three things - size
+ of its private structure, probe function and attach function;
+ this is compiled in and used in runtime - example:
+<p>
+<pre>
+struct cfattach foo_baz_ca = {
+ sizeof(struct foo_baz_softc), foo_baz_match, foo_baz_attach
+};
+</pre>
+ <li> on kernel startup, once the time comes to attach the device,
+ autoconf code calls device's probe routine and passes it
+ pointer to parent (<tt>struct device *parent</tt>), pointer
+ to attach tag structure (<tt>void *aux</tt>), and appropriate
+ autoconf node (<tt>struct cfdata *cf</tt>). The driver is
+ expected to find out if it's where it's supposed to be
+ (commonly, the location and configuration information is
+ passed by the attach tag). If yes, the probe routine should
+ return 1. If device is not there, probe routine has to
+ return 0. <b>NO STATE SHOULD BE KEPT</b> in either case.
+ <li> if probe returned success, autoconf allocates chunk of memory
+ sized as specified in device's *_ca and calls its attach
+ routine, passing it pointer to parent (<tt>struct device
+ *parent</tt>), pointer to the freshly allocated memory
+ (<tt>struct device *self</tt>) and the attach tag (<tt>void
+ *aux</tt>). Driver is expected to find out exact ports and
+ memory, allocate resources and initialize its internal
+ structure accordingly. Preferably, all driver instance
+ specific information should be kept in the allocated memory.
+</ol>
+<p>
+Example: Let's have a PCI ethernet device 'baz', kernel config
+chunk looks like this:
+<pre>
+pci* at mainbus?
+baz* at pci? dev ? function ?
+</pre>
+<p>
+At runtime, autoconf iterates over all physical devices present on
+machine's pci bus. For each physical device, it iterates over all
+devices registered in kernel to be on pci bus, and calls drivers'
+probe routine. If any probe routine claims the device by returning
+1, autoconf stops iterating and does the job described under 3).
+Once the attach function returns, autoconf continues with next
+physical device.
+<p>
+See also <a href="#adding_a_new_driver">Adding a new driver</a>.
+
<ENTRY>adding_a_system_call Adding a system call
Add an entry in <tt>syscalls.master</tt>, and add the syscall stub to the
@@ -105,6 +168,17 @@
<CURRENTSRC>/usr/src/lib/libc/sys/Makefile.inc
</tt>.
+<ENTRY>adding_a_sysctl Adding a sysctl
+See a
+<a href="http://mail-index.NetBSD.org/tech-kern/2001/06/24/0000.html">posting</a>
+answering this question on
+<a href="http://mail-index.NetBSD.org/tech-kern/">tech-kern</a>.
+<p>
+
+Note that NetBSD 1.6 and up will have a special "vendor" sysctl category
+that is reserved for vendor specific entries. See sysctl(8) for more
+information.
+
<ENTRY>mmap_in_pseudo-device How to implement mmap in a pseudo-device
Your device is most likely a character device, so you will be using the device
pager (the VM system hides all of this from you, don't worry).
@@ -201,7 +275,7 @@
</LIST>
-<a href="">Up to <em>NetBSD Documentation: Kernel</em></a>
+<a href="./">Up to <em>NetBSD Documentation: Kernel</em></a>
<hr>
<DOCLINK>
@@ -209,9 +283,9 @@
<hr>
<address>
<small>
- <a href="../../Misc/feedback.html">(Contact us)</a>
- $NetBSD: programming.list,v 1.19 2001/03/16 14:50:45 dent Exp $<br>
- <a href="../../Misc/disclaimer.html">Copyright © 1994-2001
+ <a href="http://www.NetBSD.org/cgi-bin/feedback.cgi">(Contact us)</a>
+ $NetBSD: programming.list,v 1.29 2004/03/20 20:38:25 snj Exp $<br>
+ <a href="../../Misc/disclaimer.html">Copyright © 1994-2003
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.</a>
</small>
</address>