BigPicture

Linux kernel の見取り図 †

標準ライブラリ †

Linux kernel で提供される標準ライブラリはおおよそアプリケーション向けの glibc に近い機能が提供されています。加えてビット操作と kernel 内ならではのアルゴリズム群があります。アルゴリズム群は「こんなのも有るのか」程度に知っておくと良いでしょう。アプリケーション向けに作られたライブラリが移植されていることもあるので、欲しいと思ったら Linux kernel ソースコード検索 から探してみるのも良いでしょう。

要注意なことは、アプリケーションプログラムでは普通に除算 '/'、剰余 '%' 演算子を用いた式を long long 型に対して書けば計算可能なのに対し Linux kernel 内では linux/math64.h からインクルードされる関数群を使用して関数呼び出し(あるいはマクロ呼び出し)の形で計算する必要があることです。

リンクリスト †

双方向リンクリストを操作するマクロです。リストを辿るループ処理を構成する list_for_each_entry() などの巧妙なマクロが定義されています。

アトミック操作 †

整数とビットに対するアトミック操作の機能群です。Tasklet, Work Queue などを含み、複数のスレッドや割り込みコンテキストと共有する変数、お互いの同期を取るための状態変数を操作するために使用します。ソースコード中で a++ や a |= FLAG_MASK といった式を書いたときに 変数 a は複数スレッドや割り込みコンテキストから参照・更新されるのか常に気にする必要が有ります。もし、参照・更新されるのなら spin_lock やアトミック操作が必要である可能性が高いです。

バリア指示・同期 †

バリア指示 barrier() とバリア同期 mb(), rmb(), wmb() の関数またはマクロ定義です。バリア指示はコンパイラに対して、barrier() を超えてメモリアクセス順を変更しないようにします。バリア同期は同期関数の前までに行ったメモリ操作 mb(), メモリ読みだし rmb(), メモリ書き込み wmb() を済ませるよう指示します。インラインアセンブラなどによってロート・ストアキューまたはキャッシュに保留されたトランザクションをメモリに反映します。Documentation/memory-barriers.txt を参照して下さい。

バリア同期を行ったのにデバイスの制御が不完全になっていると思われる場合、(1) レジスタの読み書きにリカバリータイム(連続アクセスする場合の待ち時間)が規定されていないか、(2) バスブリッジにトランザクションが滞留していないか 確認してください。さらに他にも原因はあるかもしれません。ここで (2) の場合について触れます。プラットホーム(SoC 内部に構成された回路ブロックやバス、基板・バックプレーン・インターコネクトで接続されたプロセッサ、チップセット、バスブリッジなどで構成されるアーキテクチャ)によっては各回路(特にバスブリッジやインターコネクト)のリクエストキューにバストランザクションがバリア指示・同期を行っても滞留する場合もあります。プラットホームのデータシートを参照して意図通りにバリア指示・同期ができているか確認して下さい。

排他制御 †

複数の処理を一貫して行いたい場合に使う関数とマクロ群です。Spin Lock は複数のバリエーションがあり、割り込みコンテキストと共に使える機能もあります。ロックを獲得できるまで CPU が Spin (空走ループ)します。短時間で済む処理をロックして行うのに適しています。空走時間が長くなる場合 CPU の処理能力を無駄に消費します。

Semaphore, Mutex は呼び出したプロセスやスレッドなどを中断して他に実行を譲れる状況で使用します。割り込みコンテキストの中から使うことは出来ません。ロックを獲得できないならば、他に実行を譲ります。

同期制御、状態変化待ち †

条件が成立するまで待つ機能、完了を待つ機能があります。別スレッドや work queue に処理を任せたあと完了を待ったり、割り込みが発生を条件に処理を進める場合に使用します。

割り込みハンドラ登録・設定 †

デバイスから来る割り込みを受ける関数を登録するための定義群です。ドライバやデバイスが外された時は登録抹消します。割り込みコントローラの制御は SoC ベンダーあるいはボードベンダーによって実装されています。割り込みハンドラに必要最低限の処理は割り込み要因を解消することです。解消しない場合は割り込み処理が再割り込みによって永遠に継続したり、2 度目の割り込みが発生しないなどの事態になります。

時間待ち、タイマー †

制御対象のデバイスはプロセッサの処理速度に比べ動作が遅いことがあります。コマンド発行間隔、要求してから結果が得られるまでの待ち時間が必要な場合が有ります。Sleep, Delay, Timer はこれらのタイミングを合わせるための機能です。注意点はこれらの待ち時間は長くなる方向でぶれます。平行して隣接する機能ブロックを操作している場合、処理や制御の重なりで思わぬ挙動を示す場合が有ります。

時刻 †

kernel 内で刻まれている時刻を取得する機能群です。jiffies はプリエンプション周期である 1/HZ 秒単位 で進む時刻です。ミリ秒オーダーの精度です。より高精度の時刻を必要とする場合は、local_clock(), sched_clock() を使用して下さい。これらは kernel が起動されてから刻まれる時刻です。現実世界の時刻と相対的な時間差があります。CPU が完全に停止した suspend 中には刻まれず止まっています。

メモリ確保 †

アプリケーションで使用している malloc(), free() の代わりになる機能です。動的なメモリ確保を必要とする場合、ほぼ kzalloc(), kfree() の 2 つで十分に対応できます。

生成したデバイスコンテキスト、デバイスに対するコマンドパケットなどの生存期間はデバイスが突然外されたり、コンテキストが複数のリンクリスト等に属する場合、特定の操作に合わせた単純な allocate - free の関係では扱いきれない場合が有ります。リファレンスカウンタ （ドキュメントは Documentation/kref.txt、ヘッダファイルは linux/kref.h) が使えないか、検討して下さい。

仮想-物理アドレス・マップ、DMA 転送、コピー †

おそらく DMA 転送を主導するようなドライバを書く機会は少ないと思います。ほぼこのような処理は SoC デバイスメーカーや開発プラットホームを作ったメーカーが提供しています。最も使うのは user space - kernel copy だと思います。ioctl(), read(), write() に対応する処理を実装すると、アプリケーションプログラムへ(から)データを転送する処理が伴います。このデータ転送は(実質的な実装がそうであっても) memcpy() を使ってはいけません。

メモリ・マップド・デバイス・アクセス †

SoC 内蔵の機能ブロック、PCI 接続のカードに乗っているデバイスはメモリにマップされたレジスタやメモリ空間があります。これらをアクセスするために用意された関数、あるいはマクロ群です。C 言語の '*' (間接演算子) を使ったアクセスは禁止されていません。しかし、関数やマクロには volatile を付加したり、メモリバリアを行ったりデバイスをアクセスする作法として必要な処理が盛り込まれています。

スレッド・軽量処理 †

「ユーザーランドの動作と独立して kernel 内でデバイスの変化に合わせデバイスを制御する。」、「デバイスが起こした割り込みに対応する。」等の処理をするためスレッド(kthread)、work queue、tasklet を利用できます。割り込み処理は request_irq() で登録した割り込みハンドラ(関数)で行います。割り込みハンドラはアトミックなので(他のスレッドやプロセスに実行を譲らないので)使用できる kernel 内の API は限られます。ハンドラは割り込み要因をクリアする事と、割り込み時に必要な処理を起床させることに専念し軽量な実装にして、割り込み発生時に必要な処理は kthread, work queue で行うのがドライバで多く見られる実装です。

スレッドか work queue か？work queue を使う方が実装量が少なく簡単です。たとえばデバイスのステータスを読み取り、ドライバで確保したデバイスコンテキストに格納するだけのような単純な処理であれば work queue を使うのが適切でしょう。ただし、work queue は手軽な代わりに複雑な処理を盛り込もうとすると、難易度が高くなります。たとえばワークを実行する関数内で再び自らを work queue に投入する様な処理可能です。しかし、何かの事象が発生し別のコンテキストが work queue に投入する処理を行う場合もあることを忘れないで下さい。

ポーリング処理が必要なデバイスであれば、kthread を使うのが適切でしょう。thread 内で wait_event_timeout() あるいは類似の関数を使用し、事象を待ちつつタイムアウトを併用して定期的なポーリングを実現します。

デバイスを制御するのに複数のステップを必要とする場合も、kthread を検討して下さい。スレッドとして動作する関数にステートマシンを実装して対応できます。

接続切断通知 †

デバイスの状態変化を通知する uevent とコネクタの状態変化を通知する External Connector (extcon, Android においては switch) が有ります。

uevent は struct device のメンバーに含まれている (struct kobject) kobj 構造体を通してデバイスの状態を通知します。

External Connector (extcon) は Android 向けに拡張された Linux で Switch として実装された class を取り込んだ物です。組み込み機器向けの機能です。主にコネクタにプラグが「接続された|切断された」事象を伝えるために使われます。キーボードに分類されないようなボタンやドアスイッチの状態を伝達するためにも使えます。

リファレンスカウンタ †

kernel API の中で *_alloc(), *_get(), *_put() のという接尾辞が付いた API の組の根幹をなすライブラリです。間接的に kobject, kmap を通して使われることもあります。接尾辞は多少の変化があります。ほぼ *_alloc() で参照カウンタ 1 でインスタンスを生成します。*_get() で参照カウンタを +1、*_put() で参照カウンタを -1 します。参照カウンタが 0 になったら、kref_put() の引数に指定された関数 *_release() が呼び出され、多くの場合インスタンスを開放(メモリから削除)する処理をします。

Kernel Object †

ノード形成 †

典型的なデバイスドライバは read(), write(), ioctl(), poll() などを通してデバイスをアクセスできるようにノードを作ります。伝統的かつ基本的な方法は character device または block device として VFS に {major, minor} 番号の組として表現したノードを登録します。登録はクラスデバイスとして登録したときにクラスドライバが代行する場合も有りますし、作成したデバイスドライバが自らする場合もあります。ユーザーランドから mknod コマンド(system call) で {major, minor} 番号の組に対応するデバイスパスを作成し、open, close できるようにします。

新しい方法、あるいは比較的軽量な方法として sysfs に(/sys 以下のノード)にデバイスの状態を read, write するためのノードを作成する方法があります。ノードの _show, _store メソッドをテキストで入出力する「気が利いた」実装にすれば、コマンドラインで cat や echo コマンドを使ってデバイスの状態を確認したり、設定することができます。

モジュールロード、アンロード、シンボル解決 †

恐らくデバイスドライバ自身がここにある API を使うことは稀だと思います。insmod, rmmod, modprobe をしたときに問題が起きた場合、何が起きているのか追跡するために参照することが多いでしょう。シンボル解決機能は興味深い機能の一つでしょう。

基本的なドライバ †

/dev/null, /dev/zero, /dev/full はハードウエアとして存在するデバイスのドライバではありません。しかし、参考になります。機能が単純なため struct file_operations のメソッド(関数テーブル)に登録する read, write といったデバイスドライバの基本的な機能実装をどのようにすれば良いか見通し良く理解できる実装になっています。

基本的なファイルシステムノード †

select(poll), ioctl を実装するのに参考になるソースを上げておきます。pipe, eventfd はデバイスから読み出すデータをキューイングする方法の参考にもなるでしょう。

デバイス登録 †

Linux ではデバイスとドライバをそれぞれ管理しています。システムに存在するデバイスの管理と、システムに存在するドライバの管理をしています。登録されたデバイスとドライバは drivers/base を核として対応付けされます。起動処理時の特殊な状況が終わった後の対応付けは device_attach(), bus_for_each_drv() と driver_attach(), bus_for_each_dev() で行われています。対応付けの処理によりデバイスとドライバのどちらが先に存在しても(後から付け足されても)デバイスに対して適合するドライバを見つけ probe 処理が始まります。

組み込み開発で良く扱うバスとそこに接続するデバイスの登録処理を挙げます。platform(SoC チップ内蔵機能、基板上でメモリ、IO 空間に固定的に割り付けられた周辺回路), I2C, SPI バス接続デバイスは固定された構成としてデバイスを登録する必要があります。PCI, USB, MMC(SD card slot) の様に動的な接続・切断に合わせてデバイスを登録・削除する処理が既に実装されている場合もあります。

ドライバ登録 †

ドライバ登録はデバイス登録と対になります。デバイス登録のところに書いたようにどちらを先に登録してもデバイスとドライバは対応付けされます。

クラスデバイス登録 †

クラスデバイスは種類別に分類されたデバイスです。種類は発揮できる機能により決まります。たとえば LED (linux/leds.h) は「発光」する種類になります。前出の「デバイス登録」でいうデバイスは回路的な機能ブロックやバスに接続されたチップを意味しています。どんな機能かという情報は含まれていません。

ドライバにより機能ブロックやチップが確かに存在し、少なくとも初期化に成功する程度に動作すると確認できたならば、デバイスを操作するためのノードを作ります。ノードは独自に作る方法と、クラスデバイスとして(分類可能であれば)登録しクラスデバイスのコアモジュールにノードを作らせる方法があります。コアモジュールは汎用的な API を提供しているでしょう。

汎用的な API は複雑に見えるかもしれません。その複雑さを追うと、kernel 内での連携、アプリケーションに対する便利なアクセス方法、汎用 API を使った実用的なアプリケーションも見つかるでしょう。多少の難しい学習をすれば周辺の開発とデバッグが大幅に楽になることがあります。

新しく Devres - Managed Device Resource が導入されつつあります。devres はデバイスコンテキスト struct device に devres_add()(内部関数は add_dr())で確保・占有するリソースを追加し、デバイス削除時に自動的に解放する機能です。devres 機能付きクラスデバイスは追加関数に接頭辞 devm_ が付きます。一覧は Devres - Managed Device Resource の後ろの方にあります。