Linuxで何らかの理由でユーザー空間からカーネル空間にコードを移動したい人もいます。その理由は、コードが特に高い優先度を持つべきか、単に「カーネル空間がより高速である」ことが多いようです。Linuxカーネルモジュールはいつ書くべきですか？
これは私にとっては不思議なことです。カーネルモジュールはいつ書くべきですか？いくつかの基準がありますか？
（私が信じる）ユーザスペースにコードを保存するように動機づける方法はありますか？
質問が正しいかどうかはわかりません。カーネル空間に物事を移動させる正当な理由があるはずです。何らかの理由がない場合は、しないでください。
一方で、デバッグはより困難になり、バグの影響ははるかに悪くなります（単純なコアダンプの代わりにクラッシュ/パニック）。
カーネルで実行されているコードは、メモリ、ペリフェラル、システム機能をユーザ空間コードとは異なる方法でアクセスするため、より効率的です。カーネルコードのセキュリティ制限が軽減されていることは言うまでもありません。しかし、これは通常、カーネルをセキュリティの脅威まで開く可能性を高めたり、OSをロックしたり、デバッグを複雑にするなどのコストをかけることになります。
カーネルに物を入れる理由は非常に限られています。あなたがデバイスドライバを書いているなら、それは大丈夫です。任意の標準アプリケーション：決して。
欠点は巨大です。デバッグが難しくなり、エラーが頻繁になり、見つけにくくなります。セキュリティと安定性を損なう可能性があります。より頻繁にカーネルの変更に適応する必要があるかもしれません。他のUNIX OSに移植することは不可能になります。
カーネルに一番近いのはカスタムファイルシステム（バックグラウンドではmysqlを使っていました）でも、FUSE（ここでUはユーザスペースを表しています）を使用しました。
原則として。あなたが知りたいことを考え、それがオペレーティングシステム開発の本やクラスで見られるものであれば、それはカーネルに属する良い機会です。そうでない場合は、カーネルから取り出してください。あなたがそのルールを破る非常に良い理由があるなら、あなた自身でそれを知るための十分な知識を持っているか、その知識を持っている人と働くでしょう。
はい、聞こえるかもしれませんが、これはまさに私が意図したことです。わからない場合は、答えがノーであることをほぼ確実にしてください。カーネルではしないでください。あなたの開発をカーネルスペースに移すことで、巨大な虫の巣が開けます。あなたはそれを確実に処理できなければなりません。
ルール：絶対を使用して、ユーザスペースにコードを保存してください。もしあなたができるとは思わないのであれば、長い時間を費やしてコードを書いているように、カーネルコードの代替案を調べるのに多くの時間を費やしてからを試してください。をユーザスペースに実装してください。 まだできない場合は、適切な選択をしていることを確認するために、非常に慎重にカーネルに移動します。他の人が言っているように、が非常に少なく、のカーネルモジュールを書くことを命令し、デバッグカーネルコードは非常に面倒なことがあります。
具体的な条件としては、カーネルモードコードの記述を検討する際には、以下の点を確認する必要があります。割込みなど、極端に低レベルのリソースにアクセスする必要がありますか？あなたのコードは、が現在エクスポートされている機能の上に構築されないができないハードウェア用の新しいインターフェイス/ドライバを定義していますか？あなたのコードは、カーネル空間からエクスポートされていないデータ構造やプリミティブにアクセスするためにが必要ですか？スケジューラーやVMシステムなどのカーネルサブシステムである他のカーネルサブシステムが主に使用するものを書いていますか（サブシステムがカーネルモードであることはまったく必要ではありません：ユーザーモード仮想メモリポケットベル、それは間違いなく実行することができます）？
あなたの人々は本当に高い優先度、決定論、低遅延などを望むなら、適切な方法はLinux（または他のOS）のリアルタイムバージョンを使用することです。
プリエンプティブなカーネルオプションなども見てください。あなたが行う必要があるのは、要件に依存しますが、ハードウェアを直接インターフェイスしている場合を除き、カーネルモジュールにコードを入れるのは正しい解決策ではありません。
遅延時間やスループットなどが必要な場合は、より安いを購入して、カーネルコードを開発するよりも高速なコンピュータを購入することができます。
カーネルモジュールは（原因少ないコンテキストスイッチ、少ないシステムコールのオーバーヘッド、およびより少ない中断に）速くなり、そして確か非常に高い優先度で実行を行うことができます。かなり単純なコードを少量のカーネルスペースにエクスポートしたい場合は、これは問題ありません。つまり、小さなコードがパフォーマンスにとって重要であると判明した場合、とは、カーネルモードにすることで利益を得ることのできるコードの一種です。それをそこに置くことが正当化されるかもしれません。
しかし、他のすべてのオプションが完全に使い果たされていない限り、プログラムの大部分をカーネルスペースに移動することは避けてください。そうすることの難しさを除けば、パフォーマンス上のメリットはそれほど大きくない可能性があります。
高速なコンピュータが存在しない場合でもコストは問題になりません。しかし、そのような場合は、リアルタイムOSに移行するほうがおそらくカーネルを破壊するよりも良いでしょう。 – Tom
基本的に、私はrpjに同意します。本当に必要な場合を除き、コードはユーザー空間になければなりません。
しかし、あなたの質問を強調するために、どの条件ですか？
ドライバによってはカーネル内になければならないと主張する人もいますが、これは真実ではありません。ドライバーの中にはタイミングに敏感ではないドライバーもあります。
たとえば、フレーマー、RTCタイマー、i2cデバイスなど。これらのドライバは、ユーザー空間に簡単に移動できます。ユーザー空間に書かれたファイルシステムさえあります。
オーバーヘッドが発生するカーネルスペースに移動する必要があります。ユーザーカーネルのスワップは、コードが適切に動作するのには受け入れられなくなります。
しかし、これに対処する方法はたくさんあります。例えば、/ dev/memはカーネル空間から物理メモリにアクセスするのと同じように、物理メモリにアクセスする良い方法を提供します。
私はRTOSに行くことについて話すとき、私は通常懐疑的です。 最近、プロセッサは非常に強力なので、ほとんどの場合、リアルタイムアスペクトは無視できるほどです。
でも、SONETを扱っていて、50ms以内に保護切り替えを行う必要があります（実際には50msの制限がリング全体に適用されるため、実際にはそれよりも小さくなります）。ハードウェアがサポートしている場合は高速です。
最近、多くのフレーマーがハードウェアサポートを提供して、実行する必要のある書き込みの量を減らすことができます。あなたの仕事は、基本的にはできるだけ早く割り込みに応答します。 Linuxはまったく悪くない。私が得た割り込みレイテンシは、他の割り込みがたくさんある場合でも（IDE、イーサネットなど）、1ms以下でした。
それでも十分でない場合は、ハードウェア設計が間違っている可能性があります。ハードウェア上に残っている方が良い方もいます。そして、私がハードウェアを言ったとき、私はASIC、FPGA、ネットワークプロセッサ、またはその他の高度なロジックを意味します。
このような質問をする場合は、カーネルレイヤーに移動しないでください。基本的には不思議なことは、あなたがする必要がないということです。コンテキストスイッチの時間はそれほど重要ではないため、最近は問題ありません。
コードをカーネルスペースに移動しない別の理由は、実稼働環境や商用環境で使用する場合、GPL契約のためにそのコードを公開する必要があるということです。多くのソフトウェア企業が参入したくない状況。 :)
セキュリティ上の問題はありません（あなたのコードは100％のハッキング証明でしょうか？ちょっとしたバグが巨大なバックドアになるかもしれません）、副次的な損傷の問題（微妙なバグはあなたのアプリよりもはるかに影響します） –