デバイスドライバモジュールの動的再変更可能な機構に
関する研究
A Study on the Possibility System of Device Driver Module that Change Dynamic 中 村 信 也 NAKAMURA Shinya ��は�めに オペレーティングシステム（以下 OS とい う）のスケジュール等のモジュールをコーデ ィングし動作タイミングを最適化するには、 何度もモジュールのコーディングと実装検証 を繰り返しその度ごとにカーネルの再構築を しなければならない。そのため動作検証には 多くの時間と労力を必要とする。また、デバ イスドライバをコーディングし動作タイミン グを最適化する場合も同様である。他方、モ ジュールをローダブルに組込み削除を行う場 合では動作検証までの時間は短縮できるが、 実際に動作させながらデバックしようとすれ ば何度も組込み削除を繰り返す必要があり、 また多くの時間と労力を必要とする。 特に、デバイスドライバはハードウェアご とに作成しなければならず、動作タイミング などハードウェアに依存するところが多くハ ードウェアに関する知識が必要となる。した がって、他の部分に比べコーディングおよび 最適化するには多くの時間と労力を費やさな ければならない。 本研究は、開発時間と労力の軽減に動的再 変更可能な機構を提案する。 ��関連研究 関連研究は、デバイスドライバコーディン グ開発労力の軽減を目的としたデバイスドラ イバ自動生成を試みた研究 1,2,3)がある。特に、 プリンタを制御対象にしたキャラクタ型デバ イスドライバの自動生成、あるいは SCSI デ バイスを制御対象にしたブロック型デバイス ドライバの自動生成 6)について成果を述べて いるものが多く、PC/AT 互換機上に搭載され た I/O やその周辺に接続された制御対象を用 いている。 また、デバイスドライバの雛形を抽象化し た自動生成の提案 4)、デバイスドライバを記 述する言語の提案 5)、共にデバイスドライバ を自動生成するため、予めハードウェアで決 定されるパラメータ設定ファイルとデバイス ドライバ本体の雛形ファイルを制作し、両フ ァイルから成るデバイスドライバを生成する 方法を自動生成と述べている。そしてハード ウェアで決定されるパラメータの設定値をフ ァイルに入力し繰り返し動作を検証している。 この方法は動作タイミングを最適化するデバ イスドライバの動作検証以前までのコーディ ング自動生成であり、デバイスドライバの開 発効率化には役立つが、デバイスドライバそ のものがハードウェアにあった動作タイミン グに設定するための最適値を検証するまでに は至っていない。このような効率化を述べて いる文献が一般的である。 特に、制御機器のデバイスドライバ開発に はペリフェラレルインタフェースの設計製作、 コーディング、接続デバイスの動作タイミン グなどの最適化が要求されるので、プリンタ 等の特定な制御対象だけではなく多くの周辺 I/O を搭載した制御対象を最適化し効率化を しなければならない。 ��デバイスドライバ実時間動作の要求 デバイスドライバの動作タイミングを最適 化するには、そのデバイスのハードウェアに 依存するタイミングにコードを的確に合わせ、 コーディング後動作タイミングが最適になっ ているのか実際に動作をさせながら検証をし なければならなくそれには多くの時間がかか り過ぎる。したがって動作検証時間を短縮す
る必要がある。 動作検証時間を短縮し最適な動作タイミン グを得るには、デバイスドライバをリアルタ イムに実時間動作を行いながらパラメータを 変更し最適値を探す調整機構が必要である。 この機構はデバイスドライバのモジュール開 発時間を極めて短縮でき開発効率を上げるこ とができる。 このような機構はカーネルの再構築を必要 とする場合、あるいはローダブルにモジュー ルを組込み削除させる場合においても実時間 動作させる機構を用いるため開発効率が極め て有効であると考えられる。そこで本報告で は、デバイスドライバを実時間動作し、最適 値を見つけ出す動的再変更可能な機構の提案 について述べる。今後本稿では、動的再変更 機構とはデバイスドライバの実時間動作中で パラメータを再変更可能な機構を示す。 �．デバイスドライバ動的再変更機構の提案 デバイスドライバをコーディングする場合、 キャラクタ型ドライバ、ブロック型ドライバ、 ネットワーク型ドライバと各種入出力用イン タフェースが必要であるが、本提案はキャラ ク タ 型 デ バ イ ス ド ラ イ バ の コ ー デ ィ ン グ と PCI バスインタフェースを用いた入出力制御 にフォーカスを絞り，Linux Kernel2.4.10 上 で動作を限定する．ただし提案の検証を簡潔 にするため本稿では割り込みは使用しないこ とにする。 PC-A DeviceDriver PC-B Emulator PCI-I/O-Interface
Dual Port RAM PCI-DPR-Interface2 Parallel I/O Controller
PCI-DPR-Interface1
X-Y-Z Table
Dual Port RAM䝟䝷䝯䞊䝍ཷ䛡Ώ䛧ᶵᵓ
䝕䝞䜲䝇䝗䝷䜲䝞ไᚚᶵᵓ 䝻䝆䝑䜽䜰䝘䝷䜲䝄 図１デバイスドライバ動的再変更機構 デバイスドライバの動作タイミングを最適 化する機構は、入出力命令、ウェイトなどの 要因に影響され、さらに各デバイスのハード ウェアに依存するため、各デバイスのパラメ ータの値を正しく設定しなければ最適な動作 が得られない。最適化する前にフリーズなど の障害が多く発生するため障害回復機構 7)も 提案されている。したがってパラメータを調 整するには、デバイスドライバを実時間動作 させロジックアナライザや負荷装置で動作確 認をしなければならない。そして適正な動作 結果が得られるまでデバイスドライバのコー ディングやそのモジュールの組込みと削除を 何度も繰り返す必要があり多くの労力と開発 時間を要する。 そこで開発時間の短縮と労力を軽減するた めに、デバイスドライバのパラメータ変更に 関わるコーディングとそのモジュールの組込 みと削除を省きパラメータの再設定ができる 機能が必要である。この機能をもったデバイ スドライバの動的再変更可能な機構を提案す る。この機構を図１に示す。 一 般 的 に デ バ イ ス ド ラ イ バ の 開 発 は 、I/O の入出力タイミングをロジックアナライザで 計測し最適化するために何度もコーディング とそのモジュールの組込みと削除を繰り返す。 その後、例えば XYZ－Table 等の要求に合っ た負荷装置を用いて動作検証を行う。このよ うなデバイスドライバ制御機構を図１の点線 枠に示す。 図１において２台のPC-AT 互換機を用い、 デ バ イ ス ド ラ イ バ を 組 み 込 ん だ 制 御 用 PC/AT 互換機を PC-A(左側)、PC-A のデバイ スドライバのパラメータを再変更設定するた めの PC/AT 互換機を PC-B(右側)とする。
PC-A のデバイスドライバすべてのパラメー タは Dual Port RAM を介し PC-B 側で再設 定できる機構である。したがってパラメータ の受け渡し機構を PC-B から PC-A に遠隔か ら設定、処理、検証ができる。このメカニズ ムを図１の破線枠に示す。また，試作インタ フェースを図２に示す。両側がマスタ，スレ ーブ PCI インタフェース，中央が Dual Port RAM である。
��Dual Port RAM の動作
何度も繰り返すコーディングとそのモジュ ールの組込みや削除、コンパイル時間を短縮 するために、デバイスドライバの I/O デバイ スに依存するパラメータだけをデバイスドラ イバから切り離し、そのパラメータを PC-B から Dual Port RAM に書き込み、PC-A 側で そのパラメータを受け取り、デバイスドライ バを動作する。
デバイスドライバ動的再変更機構は、PC-A 上にユーザープログラムとデバイスドライバ を実装し、PC-B 上から PC-A 上のデバイス ドライバのパラメータを Dual Port RAM に 書き込み、ユーザープログラムがシステムコ ールを呼び出すとデバイスファイルを介して デバイスドライバが実行し、Dual Port RAM から予め書き込んでおいたパラメータを取得 しデバイスドライバが実行される。したがっ て、デバイスドライバのパラメータを変更す ると共にユーザープログラムを実行すること でデバイスドライバを実時間動作することが 可能となる。
図 ３ Dual Port RAM を用いたモジュ ールの差し替え機構 また、スケジューラ等の開発にはカーネル の再構築が伴うので多くの労力と時間が必要 であるが、このような動的再変更機構を利用 す る こ と で ス ケ ジ ュ ー ラ 等 の モ ジ ュ ー ル を PC-A に、スケジューラパラメータを PC-B 上で書き換え Dual Port RAM に保存する。 さらに、モジュールを Dual Port RAM 上に 保存し、モジュール本体差し替え機構にも応 用可能である。図３に示す。
PC-A 上のスケジューラが実効すると、ス ケジューラパラメータが Dual Port RAM か ら予め書き込まれたパラメータを読み込むこ とで新たなスケジューラが動作できる。この ような機構を取り入れれば、何度もカーネル の再構築をする必要がなく開発時間を大幅に 短縮できる。Dual Port RAM の動作機構を図 ４に示す。 特にリアルタイムシステムなどデッドライ ンが設定されているような場合は実時間動作 ができないと最適値が検出できないような微 妙な動作タイミングを必要とする。このよう なモジュールの最適化をする動的再変更可能 な機構として使用できる。この方法は今後研 究が必要である。 したがってデバイスドライバのパラメータ 変更機能を用いた動的再変更可能な機構は、 実時間動作をしながらデバイスのパラメータ を変更することで、微妙な動作タイミングの 最適値を検出することができる。
図４ Dual Port RAM の動作機構 ��デバイスドライバのパラメータ
本稿では、パラレル I/O を用いた入出力に フォーカスをあて、キャラクタ型デバイスド ライバを用いた制御に限定する。
init_module()、 cleanup_module()、 open()、 read()、write()、release()関数の中で設定さ れるすべての変数、エントリーポイント、デ バイス固有の値を設定するために検証しなけ ればならない最適値をデバイスドライバのパ ラメータと呼ぶことにする。 デバイスドライバの動作状態を最適化にす るために下記に示す機能について検証しその 状況を表示する。デバイスドライバパラメー タ表示値を図５に示す。 次に、デバイスドライバで使用される各関 数の動作機能を以下に述べる。 図５ デバイスドライバパラメータ (1) insmod 時に呼ばれる init_modules() ①モジュール内のドライバ機能の登録状況 ②デバイスの初期化設定状況 ③return 0; で正常終了と異常終了状況 (2) rmmod 時に呼ばれる cleanup_modules() ①ハングアップの回避のため登録したドラ イバ機能の除去 ②ハングアップの回避のため要求資源の解 放 (3) open() ①マイナー番号の取得 (inode > i_rdev) ②参照カウント増加状況 ③return 0; で正常終了と異常終了状況 (4) read() ①copy_to_user ②I/O ポートアドレス，ポートデータ (5) write() ①copy_to_user ②I/O ポートアドレス、ポートデータ (6) release() ①参照カウント減少状況 (7) 関数テーブルのエントリーポイント ��デバイスドライバ雛形仕様と デバイス処理仕様の分離 デバイスドライバ生成の基本的要素である OS のインタフェースとデバイスへの入出力 方法に注目すると、デバイスドライバをデバ イスドライバ仕様、OS 依存仕様、デバイス 依存仕様の３つの部分に抽象化できる 4)。こ の方法は，デバイスドライバの自動生成する ための方法として提案された機構である。 本研究ではデバイスドライバを実時間動作 しパラメータを最適化する方法である。デバ イスを制御する場合の最適な動作タイミング を得るためデバイス自身の初期化、最適な動 作条件を得るため設定値を変更再設定するこ とで適正化する方法である。その結果、デバ イスドライバ本体の雛形部分とデバイス制御 を最適化する部分の２つに分離し構成する。 前者は、Linux-OS 依存仕様のため変更が不 必要なデバイスドライバ本体の雛形とデバイ ス制御に適したきめ細かな変数を伴った部分 をそれぞれデバイスドライバ雛形仕様とデバ イス処理仕様と定義した。デバイスドライバ ファイルをデバイスドライバ雛形仕様とデバ イス処理仕様を図６に示す。各々の仕様から 変 数 を 抽 出 し 、init_module()から writew() 関数を用いて Dual Port RAM に書き込みす る。
図６ デバイスドライバ雛形仕様とデバ イス処理仕様
書き込みデータをDual Port RAM にマッピ ングする。
８�Dual Port RAM パラメータ受け渡し機構 Dual Port RAM は IO メモリのベースア ドレスから16KB 領域が読み書き可能である。 PC-A 上のユーザープロセスからシステムコ ールを呼び出すことでデバイスドライバが処 理される。このときデバイスドライバはDual Part RAM から、予め書き込まれたパラメー タを読み込み実行する。予め書き込まれたデ ータとはデバイスドライバが初期設定するデ ータである。insmod でデバイスドライバが 組み込まれる際に init_module()関数の中で、 Dual Port RAM に書き込まれるように記述 しておく。その後、ユーザープロセスからデ バイスドライバに動作指示があれば、必要な パラメータを Dual Port RAM から readw() 関数で読み込み動作する。
この方法は，デバイスドライバ内に、Dual Port RAM のメモリ読み書き命令を付加し 動作している。図７にパラメータ受け渡し機 構を示す。また，Dual Port RAM の読み書き はページング機構を使用しいているため複雑 なメカニズムである。以下にその命令を示す。
①PC-A 側の Kernel 空間は
ioremap();、writew();、readw(); ②PC-B 側のユーザー空間は mmap();
図７ Dual Port Ram の パラメータ受け渡し機構
９�Dual Port RAM パラメータの初期設定 デバイスドライバの各関数、 open();、read();、write();、release()；は、 デバイスドライバ全体で使用するスタティッ ク変数とグローバル変数で構成されているた め、変数をパラメータ化しなければならない。 図８にデバイスドライバ変数のパラメータ化 を示す。 図８ デバイスドライバ変数のパラメータ化 insmod でデバイスドライバを組み込む際、 スタティック変数を一度グローバル変数に変 換 し た 変 数 と 、 グ ロ ー バ ル 変 数 を init_module()関数内で Dual Port RAM にパ ラメータ値として書き込みするように記述す る。その後デバイスドライバが動作すれば、 デ バ イ ス ド ラ イ バ の 各 関 数 が 、Dual Port RAM からパラメータを読み込みデバイスド ライバが実行する。図９に Dual Port RAM パラメータの初期設定メカニズムを示す。
このような方法を使用することでパラメー タを何度も再設定することが可能となる。
再設定したデバイスドライバパラメータを図 10 に表示することで最適化した値を検証で きる。 図10 デバイスドライバパラメータの表示 10．まとめ 本稿では、動的再変更可能な機構において、 デバイスドライバモジュールのパラメータ変 更のメカニズムを提案した。その結果、開発 時間と労力の軽減に動的再変更可能な機構が 有効な方法のひとつであることを述べた。 また、デバイスドライバのパラメータ変更 は、Dual Port RAM を介在することでモジュ ールの追加や削除が行われる機能の代替役割 を担うことを示した。
このような機構は、デバイスドライバの動 作タイミングを最適化するソフトウェア領域 を、Dual Port RAM を用いたハードウェアで 解決することで、ソフトウェアの開発負荷の 軽減、開発効率を上げることが可能である。 今後は、パラメータだけでなくモジュール 本体を変更する機構に焦点をあてる。 �考文� 1) 片山徹郎，最所圭三,福田晃,“デバイスド ライバの自動生成に向けて－プリンタデ バイスの生成に関する考察－”，情報処理 学会研究報告,97-OS,1997． 2) 山下勝也，片山徹郎,最所圭三，福田晃， “デバイスドライバ生成システムにおけ る入力形式に関する考察“，情報処理学会 研究報告，98-OS，1998． 3) 村上智一，片山徹郎，最所圭三，福田晃， “組み込み向け OS におけるデバイスドラ イバの自動生成について“，情報処理学会 研究報告，00-OS,2000． 4) 奥野幹也，片山徹郎，最所圭三，福田晃， “UNIX 系 OS におけるデバイスドライバ の抽象化と生成システムの実現“，情報処 理 学 会 論 文 誌 ， Vol.41No.1 ， pp.1755-1765，Jan 2000． 5) 河野真治，安里朋之，“デバイスとそのド ライバを記述するための言語”． 6) Qing-LiZhang，Ming-Yuan Zhu， Shuo-ying Chen，”Automatic
Generation of Device Drivers”，ACM SIGPLAN Notices Volume 38，Issue 6， Pages: 60 – 69，June 2003．
7) 井上翔大，大山恵弘，“デバイスドライバ のための障害回復機構”，情報処理学会研 究報告,08-OS,2008．
