2

カーネル パニック (OOPS) が発生した場合に備えて、Linux でのさまざまなログ メカニズムを調査しています。これまでのところ、ウェブでの検索から、次の情報を導き出すことができました。

  • apanic は、仕事を成し遂げるための古いメカニズムでした。
  • ram_console/persistent_ram は新しいメカニズムです。

この点について、誰かが私に次のことを教えてくれませんか?

  • 古いアジアのメカニズムとは何でしたか、これはどのように機能したか?
  • ram_console/persistent_ram メカニズムを支持して、apanic メカニズムが非推奨になったのはなぜですか?
  • 新しい ram_console/persistent_ram メカニズムはどのような利点をテーブルにもたらしますか?
  • ram_console/persistent_ram はどのように機能的に古い apanic アプローチと異なるのですか?

私はポインタと高レベルの答えを探しているだけです。ある意味で、メカニズムをさらに研究するために取ることができる方向です。この点に関する関連情報をいただければ幸いです。

ありがとう

4

1 に答える 1

5

一連の質問に対する回答を以下で見つけてください。

古いアジアのメカニズムとはどのようなものでしたか?大まかに言えば、これはどのように機能したのですか?

これは、Android でメッセージ ロギングに使用されるメカニズムです。NAND の mtd パーティションの特定のオフセットにログ メッセージを書き込みます。カーネル モジュールは、「apanic」という名前のファイルを「debugfs」にエクスポートします。以下のコマンドを使用して、debugfs を特定のディレクトリにマウントできます。" mount -t debugfs none /sys/kernel/debug" には、Linux カーネルで debugfs 構成を有効にする必要があります。詳細については、以下のリンクのソース コードを参照してください。

https://android.googlesource.com/kernel/msm.git/+/android-msm-2.6.35/drivers/misc/apanic.c

ram_console/persistent_ram メカニズムを支持して、apanic メカニズムが非推奨になったのはなぜですか?

この apanic ドライバーは、Linux カーネルの一部ではありません。アンドロイド特有です。Androidの最新バージョンでは非推奨です。その理由は、カーネル opps が発生したときに nand パーティションへの書き込みが適切ではない可能性があるためです。nand_write は遅く、書き込みサイクルが限られているためです。これは私の意見です。しかし、実際の理由はわかりません。

新しい ram_console/persistent_ram メカニズムはどのような利点をもたらしますか?

これは、Android がコンソール メッセージのロギングに使用するロギング メカニズムでもあります。ここでログメッセージは RAM 領域に入ります。persistent_ram の場合、ログ メッセージは RAM の永続メモリ領域 (保持されます) に送信されます。このドライバー モジュールは、proc ディレクトリに「last_kmsg」という名前のファイルを作成します。このメッセージは、カーネルが oops してブートを停止した場合に、次回のブートで読み取ることができます。詳細については、以下のリンクにあるソース コードを参照してください。

https://android.googlesource.com/kernel/common.git/+/android-3.4/drivers/staging/android/ram_console.c

ram_console/persistent_ram はどのように機能的に古い apanic アプローチと異なるのですか?

前者は ram ベースで、後者は mtd ベースです。

最新の実験的な Android ソースでは、両方のソースが見つかりません。理由がわからない。

https://android.googlesource.com/kernel/common.git/+/experimental/android-3.10-rc5/drivers/staging/android/

質問が明確になったことを願っています。

よろしく、

Yuvaraj.A

于 2013-08-08T08:00:18.570 に答える