議論/API再考/98.提案/ドライバフレームワーク調査のメモ


Top / 議論 / API再考 / 98.提案 / ドライバフレームワーク調査のメモ

議論/API再考/98.提案/アプリケーションとドライバの統合をもっと具体化したものになる予定。(議論/API再考/04.APIを層構造にする/e.ファイルAPIラフ案の結論を待って作業する予定)

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

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

.mjt

TODO


議論

CODECやプロトコルをドライバに含むか?

移植可能性

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

API構成

低レベルI/O API

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

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

パケットI/O API

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

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

必要な機能 :

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

【パケットが型を持たないという選択肢も有りうる】。型を持たない場合、通常のOSのioctlやread/writeによるインターフェースと同じ物になる。この場合、各プロセスの提供するチャネルはファイルシステムにマップされ、他のプロセスは通常のファイルと同じようにopenして操作することになる。また、この場合のAPIは幾つかの代表関数のcallbackとノード作成のための関数程度になり、シンプル。

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

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

【オペレーションは失敗可能】である。必要ならチャネルに対してリトライ属性を設定できるかもしれない。殆どのリトライはデバイスへの送信の段階で発生するため、同じデータをユーザから何度も書き込むよりも、書き込んだ先でリトライする方が望ましい。同じ理由で、全てのデータは一旦ドライバのプロセス空間(またはDMA空間)にコピーされることになる。

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

カーネル資源管理

このタイミングでXT-PIC以外にAPICをサポートしたいが。。

システム構成

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

カーネルパッケージ(要はRAMDISK)

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

要はpxebootやGRUB対応のため。

ブートアップデバイス

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

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

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

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

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

移植に関する問題

(全般) GPLコードの扱い

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

ビデオドライバ

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

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

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

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

他のドライバ

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

MENU

now: 3

リンク


最新の20件
2020-03-23 2020-03-17 2019-12-22 2019-07-30 2019-06-20 2019-06-19 2019-03-24 2018-10-07 2018-09-20 2017-09-29 2017-01-10 2016-12-11 2016-10-04 2016-08-14
最新の20件
2010-02-01 2010-01-31 2010-01-30 2010-01-29 2010-01-16

Counter: 1572, today: 1, yesterday: 0

リロード   新規 編集 凍結 差分 添付 複製 改名   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS

Last-modified: 2008-03-28 (金) 15:48:02 (4386d);  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.042 sec.