Linux 関数のかなり高いレベルでは、write()長さ 0 のバッファーへの書き込み要求を除外します。これは理にかなっています。実行すべき作業がないと判断するためだけに、OS がレイヤーを掘り下げて時間を無駄にしたいと思う人がいるでしょうか?
ええと...私。
これは、Linux カーネルの I2C 書き込み確認ポーリングに関連しています。また、ハンドシェイクが間違っている場合、アドレス (データの前にバスで送信される) がエラーを返す場合、ビットバンされた I2C ドライバーが潜在的に有用な戻りコードを返すという発見。
アドレスの後にダミーデータを送信できますが、私が使用しているデバイスでは送信できません。（たぶん私は読んでみます...）。
問題は、カーネルがゼロ (0) の長さの書き込みを許可した場合、どのような地獄が解き放たれるかということです。
あなたが説明していることは、予測できない量のメモリを必要とするいくつかの Windows API に蔓延するのと本質的に同じ種類の悪に相当します。実際には、作業を配置するためのバッファなしでそれらを呼び出すことです。結果を保存せずにとにかく作業を行いますが、途中で必要なバイト数を数えます。次に、そのサイズのバッファーを割り当て、サイズを認識して、バッファーを使用して関数を再度呼び出します。
これはなんとも言えない悪さです。これは、衰退した官僚機構に相当するコンピューター プログラミングです。各部門では、前の部門に提供した情報とほとんど同じ情報が記載されたフォームに記入する必要がありますが、各フォームにはいくつかの異なる情報があるため、彼らはあなたが他の人に渡したフォームのコピーを取るだけではありません. プトゥイ！
プログラマーの時間は高価ですが、CPU 時間は安価です。プログラマーが同じ API 呼び出しを N 回記述して、API 自体が独自に解決できる世界の状態を推測することを要求することは、これをひっくり返そうとします。
したがって、ベスト プラクティスは、write() が確実に成功するように、ドライバーにできる限りのことをさせることです。世界の何らかの状態をチェックすることによって成功しないことを事前に予測できる場合、おそらくそれは ioctl() である必要があります。
締めくくりとして、ドライバを更新してパッチを公開するという Warren Young のアイデアに従います (ラウンドチュートリアルを取得した場合)。
ごくわずかだと思います-一部のドライバーでは、書き込み先のバッファーにも使用可能なスペースがゼロの場合、長さゼロの書き込みがブロックされる可能性があります。長さゼロの書き込みを禁止すると、そのような場合に物事が単純になり、多くの無駄な作業が回避される可能性があります。
そのチェックを外して、実際にどんな地獄が解き放たれるか見てみませんか？:)
ioctl() を提案するのはぞっとしますが、インターフェイスに関する状態情報を取得するためのより良いインターフェイスではないでしょうか?
長さゼロの書き込みとはどういう意味ですか? 一般に、書き込みはデータの転送を意味します...そして、それをチェックしないと、ドライバーへの多くの不正な入力をキャッチすることで、より多くの問題が引き起こされると確信しています。y
それが単一ビットの情報「これを行う」呼び出しである場合は、ioctl が適していると思います。それはきれいではありませんが、何ができますか？
または、nuclear オプションを使用して mmap() を使用し、すべてをユーザー空間に移動します。オーバーヘッドが低く、「X をこのレジスタに書き込む」などの古典的な poke コードを書くことができます。
深刻な答えではありません: touch :Pのようなプログラムを取得する可能性があります
