Linux のアーティファクト:eventfd の原理と応用

Linux は、パイプ、シグナル、メッセージ キュー、共有メモリなど、多くの効率的なプロセス間通信メカニズムを提供する強力なオペレーティング システムです。しかし、よりシンプルで、より柔軟で、より効率的なコミュニケーション方法はあるのでしょうか?答えは「はい」です、それはeventfdです。 eventfd は Linux バージョン 2.6 で導入されたシステム コールで、イベント通知の実装、つまりファイル記述子を通じてイベントを配信するために使用できます。 eventfd にはカーネルが保持する 64 ビット符号なし整数カウンタが含まれており、プロセスはこのファイル記述子を読み書きすることでカウンタ値を読み書きし、プロセス間通信を実現します。イベントFDの利点は何ですか?次のような特徴があります:

• eventfd は追加のファイルやメモリ空間を作成する必要はなく、ファイル記述子のみが必要です;
• eventfd を select、poll、epoll などの多重化メカニズムと組み合わせて使用​​すると、効率的なイベント駆動型プログラミングを実現できます。 eventsfd はノンブロッキング モードまたはセマフォ モードに設定でき、異なる通信セマンティクスを提供します。
eventsfd は、プロセスまたはスレッドの境界を越えて、さまざまなレベルの通信を実現できます。
• それでは、eventfd はどのように機能するのでしょうか?どのような応用シナリオがありますか?この記事では、原理と応用の 2 つの側面からアーティファクトのeventfd を紹介します。
一般的に言えば、Linux のプロセス間通信には、パイプ、メッセージ キュー、セマフォ、共有メモリ、ソケットの 5 つの主要なソリューションがあります。

私はパイプについてあまり詳しくありません。一般的なパイプの制限と親プロセスと子プロセスの関係についてしか知りません。やりたいのは独立したプロセス間通信なので、最初は除外しました。名前付きパイプはないようです。親プロセスと子プロセスに限定されますが、カーネル状態にあります。使い方がわかりません。

Message Queueが全く分かりません。

セマフォの中核はカーネル変数のアトミック操作ですが、インターフェイスはユーザー モードにのみ反映され、セマフォの PV 操作は、私が望む通知ウェイクアップ メカニズムではなく、相互排他的であるようです。

メモリの共有はさらに厄介で、インターフェイスはユーザー モードのみにあるため、カーネル モードとユーザー モードでメモリを共有したい場合は、自分でファイルを作成して mmap インターフェイスを提供する必要があります。
ソケットは以前は af_inet の tcp/udp と af_unix の dgram でしか使用されていませんでした。問題は依然として同じです。カーネルは明確なインターフェイスを提供しません。sock->ops->recvmsg などの関数を使用して自分で呼び出すこともできますが、結局のところ、入力パラメータを自分で構築する必要がありますが、それでも安全ではないと感じられます。

残っているのは netlink だけのようです。このソケットは netlink_kernel_create 関数を明確にエクスポートしているため、カーネルのパケット送信機能を明確に提供しており、カーネル モード関数はこのソケットを使用してパケットを送信できます。しかし、1つはユーザーモードでパケット受信関数を登録する必要があり、もう1つはカーネルモードでパケットを送信するためにskbを組み立てる必要があり、単に通知で起動したいだけの私にはまだ複雑すぎます。

そこで、もう一度検索してアーティファクトのeventfdを見つけました。KVMとQemu間の通信の間で、eventfdはDanielによって見事に使用されていました。ソースコードを注意深く分析した結果、これは名前の通り、純粋に存在するものであることがわかりました。通知用に。

ファイル (Linux にはファイルではないものはありますか~~) として、その private_data 構造体eventfd_ctx には哀れな変数が 4 つしかありません。

リーリー

実際、コードを見るとより明確になります

リーリー
本質は、読み取りや書き込みを行わずに一度起動することです。eventfd_write との違いは、ブロックが必要ないことです。

私の具体的な使用法について話しましょう:

カーネル状態は、その他のデバイスを登録し、動作するカーネル スレッドを作成するモジュールです (パラメータはモジュールの file->private_data)。ユーザー モード プロセスに ioctl インターフェイスを提供して、独自のeventfd によって作成された fd を配信し、カーネル スレッドからアクセスできる file->private_data に保存します。

カーネル状態がユーザー状態に通知したい場合、eventfd_signal が直接使用されます。このとき、ユーザー状態スレッドは最初に自分自身をeventfd_ctx->wqhに配置する必要があります。解決策は 2 つあり、1 つは read を呼び出すこと、もう 1 つは投票を呼び出す。読み取りの場合、eventfd_ctx->count は後でクリアされ、次回ブロックできます。ただし、ポーリングを使用すると、カウントはその後クリアされないため、ポーリングを再度行うときにカーネル状態にeventfd_signalがない場合でも、ポーリングはすぐに返されます。

ユーザーステートからカーネルステートを通知するのは少し面倒で、まずeventfdを作成し、それをfile->private_dataに送信する必要があります（ここの操作は上記と同じです）。ユーザー状態がカーネル状態に通知する役割を担う iotcl をモジュール内に作成します。eventfd_signal は関数内で行われます。カーネル状態スレッドは最初にeventfd_ctx->wqhに配置する必要があります。vfs_readを使用するか、次のようにします。カーネル状態を自分でポーリングしてください (これも面倒なようです)。

この記事では、Linux のアーティファクトであるeventfd について紹介します。これは、シンプルで柔軟かつ効率的なプロセス間通信メカニズムです。私たちは、eventfd の作成、読み取りと書き込み、およびフラグ ビットを原理的な側面から分析し、対応するコード例を示しました。また、アプリケーションの観点から、ユーザー モードとカーネル モードの通信、タイマー、イベント トリガーなどのシナリオでのeventfdの使用法を紹介し、対応するコード例を示しました。この記事の学習を通じて、eventfd の基本的な使用法をマスターし、実際の開発で柔軟に eventsfd を使用してさまざまな通信ニーズを実現できるようになります。この記事がお役に立てば幸いです!

以上がLinux のアーティファクト:eventfd の原理と応用の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。