1

いくつかのメモリ マップ ハードウェア用の Linux ドライバーを作成する予定です (FPGA 内にあるため、必要に応じて両端でこのメモリ マップ インターフェイスを調整できます)。

この FPGA ロジックは、一連のデータグラムを生成します。これを処理してから、イーサネット リンクを介して送信する必要があります。処理またはネットワーク コードのいずれかがカーネルにある理由はないので、データのブロックをハードウェアからユーザー空間に移動するための「最良の」メカニズムについて質問しています。最大の複雑さは、ユーザー空間の処理を複数のプロセスに分散する必要があることです。

データレートはそれほど高くなく (最大 1Mbps)、mmio インターフェイスはかなり深い FIFO (現在は 2KB、最大 8KB まで増やすことができます) によって供給されるため、優先度の高いユーザーモードプロセスが追いつくことができると思います。

私が本当に欲しいのは、既存のマルチキャスト ユーザー空間インターフェイスを備えた既存のドライバーへのポインターです (それ以外はそれほど複雑ではありません)。しかし、何をしなければならないかの概要は、合理的な代用になるでしょう。

これまでに次のアイデアを収集しました。

  • AF_NETLINK: マルチキャストをサポートし、バッファリングを処理します。しかし、API は不安定で、他のインツリー ドライバーと競合する可能性のある新しいソケット ID を定義する必要があり、ユーザー モード インターフェイスは非常に特殊化socatされており、データ ストリームのテストなどの標準ツールを使用することはできません。

  • ユーザー空間からデータグラムモードのソケットまたは FIFO ファイル記述子を渡し、それに書き込みます (どのように?)。私が適用できる unix ドメイン データグラム ソケット マルチキャスト パッチがあります。

  • キャラクター モード デバイスを単一の優先度の高いユーザー モード アプリケーションに公開します。このアプリケーションは、UNIX ドメイン データグラム ソケット サーバーとして機能し、接続されている各ノードにデータグラムをコピーします。キャラクタ モード デバイスのデータグラム境界は維持されますか (つまり、ドライバ関数がバッファ サイズreadよりも少ないバイト数を返す場合、そのデータ ブロックを 1 つのユニットとして返すか、ブロックをフラグメント化して再構築できますか?の代わりに?ドライバーの読み取り関数がデータグラムが切り捨てられたことを示すために使用できるようなものはありますか、それともソケットでのみ使用できますか?)freadfreadread (2)fread (3)EMSGSIZE

  • 複数のユーザー モード アプリケーションで同時に開くことができるキャラクター モード デバイスを公開し、データを各カーネル内にバッファーします。

私は、着信パケットを再ルーティングする UNIX ドメインサーバーを備えたキャラクターモードデバイスに傾いています。これにより、カーネル ドライバー内にバッファリング ロジックを実装する必要がなくなりました。select問題は、割り込みが発生したときに呼び出しまたはブロック読み取りからユーザープロセスをウェイクアップする方法です。私のpoll関数は、制御レジスタを読み取って、POLLIN|POLLRDNORMデータが既に利用可能な場合は戻り、そうでない場合は割り込みのマスクを解除できるようです。そして、割り込みハンドラーは、準備完了 wake_upのフラグを立てるために使用します。常に割り込みをマスクします。wait_queueread

4

3 に答える 3

2

netlink が最良の選択肢だと思います。ところで、netlink ソケットを通常のソケットとして扱い、POLL、EPOLL、select を使用できます。

また、「API が不安定」とはどういう意味ですか? Netlink はよく使われ、かなりまともな API を備えています。

メッセージを送信 (および場合によっては受信) するには、一般的な netlink を使用する必要があります。一方向の通信、つまりカーネルからユーザー空間への通信があれば、作業はさらに簡単になります。

編集：アクセスできる場合は、ページを参照してください。Wrox 著 Professional Linux Kernel Architecture の 810 以降 (第 12 章)。私の知る限り、ユーザーランドとの通信に netlink を使用する方法について (比較的) 適切に説明されています。

netlink の唯一の欠点は、ドキュメントが乏しいことです。そうでなければ、私の意見では大丈夫です。

于 2011-04-27T20:46:31.017 に答える
1

より多くのドキュメントを見つけることができ、カーネル部分がより単純であるため、char ドライバーの方が良いオプションだと思います。この API はよく知られており、char ドライバーの経験がある人が多くいます。

小さく始めます。つまり、作業中の割り込みベースのブロッキング読み取りから始めます。

  • 利用可能なデータがない場合は、キューでスリープします
  • そうでなければ、利用可能なデータをユーザー空間に返します。

割り込みルーチンを使用して、データが利用可能な場合、最終的にキューをウェイクします。

動作したら、ポーリングを実装します。

于 2011-04-28T10:58:01.537 に答える
1

キャラクター デバイス オプションを使用すると、read(2)from ユーザー空間はドライバーのread()関数 (struct file_operationsデバイスを登録した で指定) を呼び出すことになります。したがって、データグラムの境界を維持するかどうか、およびさまざまな失敗の場合にどのエラーを返したいかは、実装次第です。

于 2011-05-04T03:06:51.617 に答える