議論/API再考/98.提案/ドライバフレームワーク調査のメモ のバックアップソース(No.1)


#setlinebreak(on)
#topicpath

[[議論/API再考/98.提案/アプリケーションとドライバの統合]]をもっと具体化したものになる予定。

※ 調査過程のメモなのでまだAPIについて書くことは無い。少々お待ち下さい。

※ 現在の所、デバイス = プロトコル = 他のユーザプロセス。 - これには多分議論が有る。

[[.mjt]]

* TODO [#g00127fb]

- パケットI/O APIが一番のキモだけど[[議論/API再考/04.APIを層構造にする/d.OS機能をSchemeで提供]]待ち。
- サンプル実装(多分[[USB]])

----

* 議論 [#cf2610eb]

** CODECやプロトコルをドライバに含むか? [#wa4f8938]

** 移植可能性 [#bb0e37d1]

(Mona以外でも役に立つんじゃないかというタッチの話)

* API構成 [#n3c25e65]

** 低レベルI/O API [#u9780059]

デバイス列挙プロセスや、その他のプロセスがデバイスを直接制御するためのAPI。おそらくwinring0互換か同じような関数セット。

- 物理メモリアクセス
- x86 I/Oポートアクセス (inp,outp)

これらは調停されない。つまり、一度デバイスへのアクセスを許可したらOSはその動作には関知しない。例外は割り込み。

** パケットI/O API [#p831f166]

【普通のユーザプロセスが使うファイルAPIと事実上同じ物。であることが望ましいが。。】

- USB
- ネットワーキング(TCP/IP , UDP , Ethernet)
- アプリケーションプロトコル(HTTP,)
- ファイルシステム
- カーネルメッセージング
- 他、デバイスドライバプロセスによって提供されるデバイス制御API

パケット単位でやりとりされるデバイスまたはプロトコルの制御。

必要な機能 :
- パケットの送受信(CまたはScheme関数としてデバイス個別にエクスポート)
- パケットのパース(CまたはScheme関数としてデバイス個別にエクスポート)
- パケットの構成(CまたはScheme関数としてデバイス個別にエクスポート)
-- これらはRPCのような形で関数として呼び出せると良い
- バッファ(音のストリーミング、ディスプレイリスト)
- 受信待ちなどスレッド調停
- 例外の処理(タイムアウト、デバイスエラーなど)

【パケットは型を持つのが望ましい】。つまり、"HTTP Request"とか"TCP Packet"といった型をユーザアプリケーションが提供し、カーネルのプロセスマネージャが適切な処理先を検索して処理させる。

Packetをストリームにしたり、その逆が必要。1byte単位での入出力を行うデバイスは現代となっては非常に少数派なので、これを適切に抽象化するのは重要と考える。例えば、TCPや音声入出力、MPEGのようなビットストリームのフレーミング等。

【全てステートフル】となる。一度チャネルを確保し、それに対して送受信を行う。

【オペレーションは失敗可能】である。必要ならチャネルに対してリトライ属性を設定できるかもしれない。

現在の所、これらはSchemeに対してプレーンなファイルアクセスAPIを提供するという[[higepon]]の方針に反する。要調停。


* システム構成 [#vc143ce8]

この議論が何気に難しい。

** カーネルパッケージ(要はRAMDISK) [#kc508c33]

【カーネルと起動に必須のドライバを1つのファイルに纏め、起動時に展開する技術が必要。】

要はpxebootやGRUB対応のため。

** ブートアップデバイス [#sc05e274]

起動に必要なデバイスのドライバはカーネルパッケージに含める必要がある。ファイルシステムやHDDまたはCDまたはネットワークに到達するまでのバスドライバ等。

個人的にはOSの提供するドライバのうち、【ファイルシステムと純粋なハードウェアドライバは全てカーネルパッケージに含めてしまって良い】と思う。OpenGLのような例外を除いて、各々のサイズは十分に小さい。

** プロセスの分類 : デバイス列挙 , 通常のコンシューマ [#p558b2d3]

【新たにデバイスenumeratorプロセスを用意する。】平たく言えば、バスを検索して適宜適切なデバイスドライバを起動するプロセス。

Linux等と異なり、個々のデバイスドライバを順番にコールするわけにはいかない(プロセスのロード/アンロードを伴い時間が掛かる)ので【enumeratorは、IDの組と対応するドライバの名前を知らなければならない】。実際には個々のアプリケーションが対応するパケットの型が明示し、それを利用する事になるだろう。



* 移植に関する問題 [#hc051c39]

** (全般) GPLコードの扱い [#t729d8c5]

これはアプリケーションのコンパイル環境がカーネルから分離されれば自然に解決する。

** ビデオドライバ [#e2c4a8b6]

ビデオドライバはXのものとDRIを移植できるように(多分僕が)努力する。

APIはおそらくSDL程度の物とOpenGLだけを提供し、Xlibは提供されない。現状のXorgはXMLで記述されているのでビルドの手間が増える問題があるし、おそらくXそのものは求められていない。

PCIeを実装するためにカーネルにおけるメモリマップ機能の再検討が必要かも知れない。

【現状のVESAコンソールやGUIと共存できないため何らかの対策が必要】。

** 他のドライバ [#a41c3ba0]

基本的にビデオドライバ以外は積極的な移植の方法論を考えていない。

トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS

Modified by mona
PukiWiki 1.4.6 Copyright © 2001-2005 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji
Powered by PHP 5.2.17
HTML convert time to 0.032 sec.