TechNote by 古賀信哉

技術情報のメモ書き(備忘録)

広告

※このエリアは、60日間投稿が無い場合に表示されます。記事を投稿すると、表示されなくなります。

最近は、こちら

2010-12-10 00:32:17 | MISC
ここの Blog を、5年半放置したままになっていました。今のところ、技術ネタの話は、Twitter でつぶやくか、または、WinCE 関連を
 http://www.stprec.co.jp/ceblog/author/koga/
に書いています。

以上、5年半ぶりの近況報告です。
コメント (1)

Windowsのデバイスドライバ

2005-06-12 17:44:57 | Kernel land
僕が持っている、WindowsNT系のデバイスドライバに関する解説書は、3、4年前に購入した"The Windows2000 Device Driver Book"だけなのですが(ちなみに、この本のサポートサイトにあるerrataリストの先頭にある、本の内容において本質的でない間違いの訂正は、僕の指摘によるものです)、ちょいと入り用になって、より具体的な情報をMicrosoft社のサイトで探してみました。

以下に、それらリストアップした中から選んだものをまとめます。ちなみに、WinDDKは、MSDN subscriptionのサービスを購入しないと現在は入手できなくなっているので(Win98/Me用のは、現在もフリーでダウンロードできるようです)、そちらの情報は含めません。

・ファイルシステム以下のデバイスドライバ階層に対する解説
 - ドライバ階層を説明したプレゼンテーション資料
 - IRP(I/O Request Packet)が階層を伝播する様子の実際を説明したプレゼンテーション資料

・ストレージデバイス全般に対する解説資料
 - 解説資料のリンク集

・サンプルコード
 - ディスクデバイスを列挙するプログラム
 - filter driverを直接アプリケーションから開いてioctl()可能にする方法(コードの例示)

ストレージデバイス全般に対する解説資料のページにある、一昨年と昨年のWinHECのプレゼンテーション資料の中には、以前は"Cobra"というコードネームで呼ばれていたらしい、Windowsの新しいデバイスドライバのフレームワークを紹介したものがあります。これは、WDF(Windows Driver Foundation)という正式名称になり、現在β版が限定提供されています。おそらく、"LongHorn"かまたは、その後のメジャーバージョンアップ版のWindowsに組み込まれるのでしょう。

ストレージ周りのデバイスドライバの階層構造は、現在のWDM(Windows Driver Model)における構造に改良が加えられ、特に、filter driverにおける開発効率と実行効率を向上させるためのアーキテクチャ変更が行われているようです。

現在、WDMのfilter driverは単体のデバイスドライバであり、そのため、attachする(フックをかける)対象のデバイスドライバとの間では、通常のドライバ階層と同じく、IRPを受け渡ししなければならず、また、PnPや電源管理のコードも実装しなければいけません。これに対し、WDFにおいては、コールバック関数を用いてfilter driverの呼び出しを行うようで、そのため、filter driverをより軽量化でき、デバイスドライバ(.sys)というよりは、カーネルモードのDLL(.dll)といえる存在になるようです。

さらに、filter driverをpre filterとpost filterに分けてattachできるようになるため、attachされたデバイスドライバが処理を行った後でfilter driverが処理をしたい場合には、単にpost filterとして登録すればよく、現在のWDMのように、attachされたデバイスドライバにcompletion routineを渡して処理する、という必要もなくなるようです。

WDFにおけるデバイスドライバアーキテクチャの変更は、デバイスドライバのPnP(プラグアンドプレイ)機構を改善させたWDMに続き、より洗練されたプラグインアーキテクチャに進化する方向だと言えるでしょう。
コメント (20)   トラックバック (1)

fskit〜Dominic Giampaolo

2005-06-07 22:21:20 | Kernel land
ちょいと入り用になって、途中まで読んだまま長らく「積読(つんどく)」状態になっていたPractical File System Design with the Be File Systemを手に取りました。

で、買った当時は見落としていたのだけれど、ファイルシステム実装途中のテスト用に、著者のDominic Giampaoloが作った"File System Construction Kit"というツールキットの説明が付録に載っており、そのソースが公開されているのに気づきました。こいつは、ごく基本的なファイルシステム機能をfilesystem on fileとして実装したもので、user landで動かせるもののよう。こいつが、入り用のものでした。ファイルシステムの下回りで動くコードを書く際、実際にファイルシステムへ組み込んでカーネルモード(kernel land)で動かす前に、上位側のスタブと、下位のストレージデバイスのエミュレータを書いて、user landで動かして基本動作をテストするのに使えないかと思った次第。

以前にも、ちょっと似たことをやりたくなって調べた際、GNOME関連かLinux本体の方だかで、user landでファイルシステム機能を動かす仕組みみたいなのを見かけたのですが、それなりに大掛かりだったような気もするし、Linuxでしか使えないというんだと、ちと不便なので、こちらの方が便利そうです。

さて、解説書の付録に載っていたURL(http://www.mkp.com/giampaolo/fskit.tar.gz)をアクセスしたところ、ページが無いという状態になってしまってました。知らなかったのですが、出版元のMorgan Kaufmann Publishers, Inc.(http://www.mkp.com)が別会社に買収されたかしたようで、解説書も絶版になってしまったので、置き場所がなくなっているようです。で、'giampaolo+fskit'でgoogle検索してみたところ、一つ見つかりました。さらに、BeOS関連のサイトにあったMLのアーカイブには、Open BeOS(※現在は、"Haiku OSと改名)のプロジェクトで改訂を加えられた版へのリンクを記した記事も見つかりました。

解説書に書いてあったページが無くなっていたのを知った時は、「どうしたもんだべか」と思ったのですが、一安心。ちなみに、"Haiku OS"の開発進捗状況を見たところ、二年くらい前に見た時から、あまり変わっていないような感じです。以前のものと思わしきページと比べると、カーネルがプレ・アルファからアルファに進み、印刷回りがベータ途中からベータへ進んだくらいでしょうか。

さて、首尾よく入り用のものを入手したところで、著者のDominic Giampaoloのページがないか探したところ、ありました。Be, Inc.が技術資産をPalmSource社に売却し、解散状態になった後、彼がGoogle社へ移籍したというのは噂で聞いていたのですが、彼のページを見たところ、その後、QNXでも仕事をし、今は、Apple社にいると書いてあります。Apple社で何をしているかといえば、Spotlightの開発に携わっているのだそう。そう言われてみれば、とっても納得です。

「技術は、企業に所属するのではなく、人に所属するのだ。」というのは、昔から耳にすることですが、その実例の一つが、彼なのだなあと実感しました。SGI社IRIXのファイルシステム(XFS)を開発し、その後も、移籍先ごとにファイルシステムを作り続ける、"filesystem guy"なのですね。ちと感動です。

なお、上に書いたDominicのページでは、絶版になった"Practical File System Design with the Be File System"のコピーも公開しています(PDFのリンクがあります)。書店では入手できなくなった解説書を読んでみたい人は、アクセスしてみて下さい:-)
コメント (1)   トラックバック (203)

Mac OS Xでビルド

2005-05-12 18:20:29 | 移植性
AVIライブラリを、Mac OS Xでビルドしてみたら、まずはコンパイルエラー。big endianな環境での動作確認をするためだったのですが、コンパイラのpredefined macroでLinuxとWin32にしか対応していなかったので、追加作業が必要でした。

まず、Mac OS X/Darwin用gccのpredefined macroが何か分からなかったのですが、Appleのサイトで検索したところ、一覧がありました。ここの"Predefined Macros"の説明によれば、Mac OS X用のコード部分を指定するには、
 #if defined(__APPLE__) && defined(__MACH__)
 ...
 #endif
としてやるのが正しいようです。

次は、リンクオプション。DLL/shared libraryをビルドして使うのは、XCodeでは既にやってあったのですが、Makefile&makeでは試していなかったので、再びdeveloper.apple.comで検索。Linuxだと-sharedオプションを使えますが、Mac OS Xではサポートされていないので、-dynamiclibオプションに切り替える必要があります。この時点でめんどくさくなり(だって、あくまでもbig endian対応のテスト用だもん)、Mac OS X用のMakefileは、Makefile.macosxという別名にしました。

さらに、DLL/shared libraryの拡張子は、.soじゃなく、.dylibにしないといけません。ここに至って、Mac OS Xの実行ファイルフォーマットがELFじゃないことを思い出しました。Mac OS Xにおいて、Classic Mac OSがPowerPC対応した際にCFMと共に導入されたPEFを使わず、NeXTStep時代から引きずってきた、Mach-Oを採用したのでした。ちと気になって、"Linkers & Loaders"を見てみましたが、PEFもMach-Oも、載ってません。どちらもマイノリティなのですね;-)

閑話休題。ビルドの話は、まだ残る。DLL/shared library(Mac OS Xの用語だと、dynamic libraryになるようです)をリンクしたプログラムを動かす際の環境変数は、DYLD_LIBRARY_PATHです。setenvで、こいつにパスを突っ込んでやって、ようやく動かすことができました。残りは、AVIファイル中の整数値をバイトスワップ(エンディアン変換)する追加コードを書けば、ライブラリのbig endian対応が終わりです。もうちょっとで完了だ。
コメント   トラックバック (1)

AVIのメタインデックス

2005-05-09 03:36:50 | ファイルフォーマット
仕事絡みで書いていたAVIファイルの読み書きライブラリで一つハマっていたのですが、ようやく解決しました。ハマっていたのは、自作のライブラリで作ったAVIファイルをWMP(Windows Media Player)で再生すると、スライダーを動かして任意位置にシークした時に、音声出力が止まってしまうというもの。

自作のライブラリが吐くAVIファイルをWMPで再生した時は、シーク時の音声提示に上記の問題があるのに、そのAVIファイルをGraphEditで編集してDirectShowのフィルタ連結を組み替え、AVISpliter→AVIMuxer→FileWriterという連結にしてAVIファイルを再作成すると、再作成したAVIファイルの再生は、WMPで問題なく再生できるのです。ちなみに、VideoLAN Clientでは、どちらも問題ありませんでした。

WMPがインデックスを見失っているようだとは分かるものの、映像の方は問題なく再生できるので、原因を追跡していたのです。AVI 2.0、つまりOpenDML拡張版の仕様に基づくファイルフォーマットでAVIファイルを作り、さらに、独自定義のチャンクを挿入していたので、原因を切り分けるため、音声ストリームのみのAVIファイルを吐き出すようにして追跡したところ、ようやく分かりました。

音声ストリームの場合、映像とは異なり、一つのフレームのデータが小さいので(16bitのPCMステレオ音声で、フレーム当たり4byte)、映像の一フレーム相当程度の時間分を一つのチャンクにまとめて書き込むのですが、その際のフレーム数の扱いが原因でした。OpenDML拡張におけるメタインデックス(index of index; 'indx'チャンク)では、メタインデックス要素のduration値として、「そのストリームのtick数」、つまりフレーム数を記録することになっていますが、ここに、インデックス個数、つまりチャンク数を記録していたのが原因でした。正しくは、チャンク数ではなく、実際のフレーム数を記録しなければいけません。

その修正を施したところ、自作ライブラリで作成したAVIファイルをWMPで再生し、スライダーで任意位置へシークしても、音声出力が止まることなく、正常再生できるようになりました。やれやれ。

ここに行き着くまでには、WindowsのSDKにあるヘッダファイル(aviriff.h)にコメントで書かれているように、'movi'チャンクのリスト要素開始位置などを、512byteのセクタサイズで整列させるようにしてみたりもしたのですが、それは必要ないということを確認できました。
コメント

monitorとsemaphore

2005-04-29 18:31:56 | マルチスレッド
暫くぶりで、まとまった量のコードをJavaで書いたのですが、Javaの排他制御機構は、それほど悪くないなという感想が残りました。この点、以前とは、少し印象が変わったところです。

C/C++でマルチスレッドのコードを書くと、セマフォやロック(mutex)を使った排他制御が基本になって、Javaが基本とするmonitorを、いわばバラした形で使うわけですが、プログラミングのうえで「間違いをしづらくするための制約」という観点からすると、Javaのmonitorは、悪くない力を与えているなと思い直しました。

たとえば、producer/consumer型のマルチスレッドプログラミングを行う場合です。カウンティング・セマフォを使えば、consumerのキューが空になった時の待ち動作と、producerがキューへ処理対象を投入した際の通知動作が、セマフォだけで実現できてしまうわけなので、Javaのmonitorは、大げさ過ぎて邪魔に思えます。しかし、キューの実装によっては、キュー要素の取り出し(dequeue)と投入(enqueue)がthread safeではなく、それらに対する排他制御が必要になります。

さらに、producerとconsumerが、どちらも処理を終えた場合に全体動作を完了させる、といった仕組みを入れようとすると、特に、consumerに複数のスレッドを割り当てる場合には、それらに付随した共有情報を管理しなければいけません。

そういう場合には、Javaのmonitorを使う方が、融通が利かない分、却って詳細設計をやり易いなと感じました。つまり、java.lang.Object.notify[All]()は、それを呼び出した時点で、同じオブジェクトに対するjava.lang.Object.wait()を呼び出して待ち状態に入っているスレッドがないと、何の効果も生まないため、カウンティングセマフォの場合に比べると、待ち動作と通知の実現において、余分な情報を管理しなければいけません。同期のさせ方が単純な場合には、Javaのmonitorは、うざったいだけなのですが、多少なりとも込み入ってくると、むしろ、使い方をきちんと考えなければいけないぶん、Javaのmonitorの方が使い良い局面があるわけです。

Javaの言語仕様では、monitorを基本に据えた同期機構について、フレームワークという呼び方をしていますが、確かに、そうだなと思いました。

以前、マルチプラットフォーム用のスレッドライブラリを仕事で作った際、C++のライブラリAPIとして、java.lang.Threadに似たインタフェースを持つクラスと、入れ子ロックが可能なロックのクラス、および、pthreadsで言うconditional variableや、Win32 APIで言うeventのような待ち動作用のクラスを作ったのですが、今回の仕事を終えてみて、Javaのsynchronized節のような書き方のできる、monitorのフレームワークがあると、より良い局面があるなと思い直しました。そのライブラリを作った当時は、Javaのmonitorなんて、うざったいだけだと考えていたのです。

そういえば、AppleがXCodeに入れている版のObjective-Cだか、純正gccがサポートしているObjective-Cだかで、Javaのと似た構文で同期や例外処理を書ける糖衣構文(syntax sugar)が導入されたようですが、それもまた、悪いことではないなと思います。
コメント   トラックバック (1)

Technorati API

2005-04-04 02:25:40 | Webサービス
Technorati JAPANのサイトでは、キーワードとURLによる単純なBlog検索のインタフェースしか提供されておらず、http://www.technorati.jp/search/search.htmlというCGIに、"query"というパラメータでキーワードかURLを指定することしかできません。

このCGIに渡す"query"パラメータは、それがキーワードの場合には、そのキーワードを含むBlogページの一覧を出してくれますし、URLの場合には、そのページにリンクを張っているBlogページの一覧を出してくれます。検索結果として出力されたBlogページの一覧には、「リンクを見る」という項目があり、そいつをクリックすると、そのBlogにリンクを張っている他のBlogの一覧を検索できます。HTMLのソースを見ると、「リンクを見る」を囲ったa要素のhref属性として、'search.html?query=<そのBlogのURL>'という指定をしています。

JAPANのサイトでは、α版ということで、お手軽インタフェースしか提供されていないようですが、USのサイトでは、"API"として、CGI呼び出しのインタフェースが細分化されています。上のキーワード/URL検索の場合だと、それぞれは、"Search query"、"Cosmos query"という二つのCGIに分割され、googleの検索APIのように、検索結果が大量にある場合に、それらを分割して指定して取得することも可能になっています。また、JAPANのサイトでは検索結果がブラウザ表示用のHTMLテキストとして返されますが、USのサイトで提供されているAPIでは、CGIが返す検索結果は、より軽量なXML文書です。

ただし、そのサービスを使うには、googleの場合と同じように、ユーザ登録してAPIキーを取得し、そいつをCGIパラメータの一つとして渡さなければいけません。C++の擬似コードで書くと、次のようになります。なお、以下の擬似コードにある、"HttpFetch"というのは、指定したURLに対してHTTP GETし、HTTP responseで得たデータをstd::stringに格納して返すGet()というメソッドを持つクラスです。

HttpFetch httpClient;
std::string result;

httpClient.Get(
"http://api.technorati.com/cosmos?" // "Cosmos query"のURL
"key=<APIキー>" // APIキーを指定
""&url=http://www.kuniritsu.com", // 検索キー(URL)を指定
&result);

USのサイトには、開発者向けのエリアがあり、そこでは、APIが返すXML文書のDTDなど、技術情報が公開されています。上記のAPI呼び出しと、APIが返すXML文書を解析してBlogページ属性の一覧にアクセスするコードも、それら開発者が登録したものが公開されており、JavaやC#、PHPで書かれたものがありますので、それを組み込んでアプリケーションを作ることが可能です。

さて、APIが返すXML文書のエンコーディングがUTF-8ですので、Javaで書くのが楽は楽なんですが、HTTPアクセスやXMLのパーザなど、下位のライブラリを整備するためのターゲットとして、C/C++で書いてみようかと思っています。とはいえ、単にライブラリだけ書いても面白くないので、TechnoratiのAPIをうまく使ったアプリケーションを考えなければいけません。

昔、MagicCapTeleScriptの資料を見ていた時に、「検索エージェントがネットワークへ出掛けて検索結果をかき集めてくる際に、他のエージェントと情報交換して、同じような検索を実行しているエージェントがいたら、検索から戻って来た時に、そのエージェントの使い手とコンタクトするヒントを教えてくれる。」というのを考えていたのですが、そういうものに繋げられたら面白いんじゃないかと思います。

ところで、いまMagicCapについて検索してみたら、こいつを開発していたGeneralMagic社は、2002年に廃業してしまっているのを知りました。一時は、TeleScriptで実現していたエージェント機構の実装をJavaに置き換えるなどして生き残りを図っていたのですが、うまくいかなかったようですね。
コメント

開設初日

2005-04-03 16:16:18 | Weblog
会社のWebに「社員日記」のページを設けることにしたのですが、自分の番が回ってきた時のために、公開型の日記サイトか、国内のBlogサイトを使おうと思い、無料Blogサービスの比較が載ったページでここを見つけ、使ってみることにしました。

とりあず、ping先にTechnorati JAPAN(http://rpc.technorati.jp/rpc/ping)を指定してみました。Technorati JAPAN(テクノラティ)のBlog検索サービスは、まだα版なのですが、自分のページが検索でヒットするかどうか、試してみます。
(2005-04-03-16:32時点では、ヒットしません。一日待って、再度試す予定。)

・2005-04-04-12:14時点でも、まだヒットしません。検索でヒットするページを見ると、10時間前のやつもありますから、pingサーバ内のDB更新が間に合っていないというわけでは、なさそうです。XML-RPCのURLも再確認しましたが間違っていませんので、どうやら、登録されるための何らかの閾値があるのでしょう。他のpingサーバと比較するために、ココログのやつを更新先に追加してみました。もう一日待って、再度試します。

・2005-04-07-15:56現在、"TechNote"でヒットするようになっていることに気づきました。昨日は忙しくて試せなかったので、いつヒットするようになったのか、正確なところは不明です。なお、"古賀信哉"で検索しようとすると、「システムエラー」が出てしまいますX-(

テクノラティ:
http://www.technorati.jp/home.html
コメント