問題タブ [xnu]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
ios - 名前付き OSMallocTag を作成したライブラリを見つけることはできますか?
iOS アプリのヒープ使用量を測定するために割り当てインストゥルメントを使用しています。タグ名「Memory Tag 70」の領域に大量のメモリが割り当てられていることがわかりました。追跡できるように、その責任者を知りたいです。
- この記憶について何かしようとすることが適切かどうか
- もしそうなら、私はそれについて何をすべきか (つまり、どのコードがその領域にオブジェクトを割り当てているか)。
OSMalloc_tagAlloc()
では、特定の引数を持つ への呼び出しがどこから来ているのかを追跡できますか? デバイス上ではなく、シミュレーターで実行している場合にのみ実行できる可能性があることを受け入れます。しかし、それが事実である場合、どうすればよいでしょうか。タグ名を表示できますか?dtrace
もしそうなら、シミュレーターでアプリを起動できdtrace -c
ますか? どのように?
macos - Mac OS X カーネル拡張でキャッシュするために OS によって再利用されるメモリ バッファを割り当てるにはどうすればよいですか?
私が読んだドキュメントと xnu ソースに基づいて、Mac OS Xは Unified Buffer Cache (UBC) を使用してファイルI/O をキャッシュすることを理解しています。UBC は、使用可能な RAM に基づいて可能な限り大きくなりますが、UBC ページは、メモリが不足したときに最初に犠牲になるページの一部です。
私のドライバーでは、ディスク上のさまざまなメタデータを扱います。UBC や同様のメカニズムを使用して、このデータの MRU キャッシュを維持し、速度を向上させたいと考えていますが、カーネルが必要なときにいつでもそのメモリを取り戻すことができるようにしたいと考えています。ただし、メタデータはファイルデータを表していないため、UBC のドメインに直接分類されません。使用できる下位レベルのメカニズムはありますか、またはバッファー自体を処理する UBC の一部のみを使用できますか?
私は現在、HFS+ のソース コードを調べて、ファイルシステムのメタデータをキャッシュするかどうか、およびその方法を調べていますが、あまり成功していません。
もちろん、主な代替手段は、キャッシュ用に特定のメモリ領域を予約し、独自の LRU カリングを行うことです。固定キャッシュ サイズを選択するか、ある種のヒューリスティックを使用することができますが、RAM が豊富な場合はメモリの使用量が少なすぎ、そうでない場合はメモリが多すぎます。
アップデート:
さらに検索したところ、 のインスタンスがオプションIOBufferMemoryDescriptor
で作成される可能性があることがわかりました。これにより、破棄するメモリ「公正なゲーム」をマークするためにそれをkIOMemoryPurgeable
呼び出すことができます。IOMemoryDescriptor::setPurgeable()
私はそれを試して、結果で質問を更新します。
process - 「jetsam の優先順位」とは何ですか?
誰かが「ジェットサムの優先順位」とは何かを説明できますか?
それらはlaunchdによって強制されるものです。特定のプロセスの CPU を調整する方法ではないかと思いますが、確かなことはわかりません。
kernel - カーネルを別のアーキテクチャに移植しますか?
xnu
Qemu内で完全なカーネルを実行できるようにするという最終的な目標を持って、カーネルをARMアーキテクチャに移植したいと思います。これは非常に難しい作業だとは思いますが、それでもやってみたいと思います。
私の知る限り、カーネルのエントリポイント(osfmk/arm/start.s
)を記述して、一般的な初期化(MMUおよびPlatformExpert)を実行した後、Kext / IOKitサブシステムを起動し、CPU固有の拡張機能(トラップ、 GPIO、クロック)バイナリに事前リンクされているか、ブートローダーによってロードされます(NAND拡張機能がまだ利用できないため、カーネルがファイルシステムと対話できないため)。
ARM CPUがどのように機能するかについての一般的な考えはありますが、ポートをどこから始めればよいかさえわかりません。これは、次のxnu
方法が完全にはわからないためです。
- 低レベルのデバッグを実行します(起動中の早い段階でカーネルデバッグ機能を使用できないため)。
- ARMブランチを残りのカーネルソースツリーと統合します(つまり、中のもの
osfmk/kern
が機能していることを確認します)。 - プラットフォームに依存しないカーネルを開始するための適切な環境を作成します(
machine_startup()
); - メインカーネルコード内のいくつかのプラットフォーム固有のコードを修正します(プラットフォームコードのほとんどはに制限されて
osfmk/platform_name
いますが、一部は他のコードに統合する必要がosfmk/kern
あります)。
Linuxガイドと同じように、 XNU(または少なくともMach )カーネルをさまざまなプラットフォームに移植するための適切なガイドはありますか?
macos - OS X はどのようにクラッシュ レポートを生成しますか?
Web、メーリングリスト、Mac OS X Internalsのような書籍、さらにはソースコードから入手できる資料はかなり限られています。
これで、xnu カーネルが EXC_CRASH を発生させ、「Problem Reporter.app」を起動するように通知することがわかりました (以前は Crash Reporter.app でした)。このアプリはデバッグ インターフェースを使用してクラッシュ レポートを生成していますか?それともカーネルが既にレポートを生成しており、既に生成されたレポートを開くようにアプリに通知するだけですか?
macos - lsyncd が xnu を必要とするのはなぜですか?
Mac OS X (正確には 10.7.3) で lsyncd をコンパイルする手順を実行しています。
lysncd のソース コードにいくつかのマイナーな構文エラーがあったにもかかわらず、最終的になんとかコンパイルすることができました。Axel Kittenberger (lsyncd を管理する開発者) から、コンパイルには XNU が必要であることがわかりました。
参考文献:-
構成手順は次のように行われました:-
続いて、新しく作成された Makefile (asciidoc へのパスを自分の macports asciidoc の場所に変更することに関連) にいくつかの小さな変更を加えて実行します。
それですべてうまくいき、最終的に結果のlsyncd
バイナリを手に入れました。
私の質問は、なぜこのプロセスで xnu が必要だったのですか? (知りたいです)
macos - vnode_t はどこで定義されていますか?
vnode_t
として定義されている a を使用しようとしていstruct vnode *
ます。への参照はたくさん見つかりますがstruct vnode
、定義されているヘッダーが見つかりません。誰でも助けることができますか?
macos - カーネル エクステンションが kernel.log に書き込まないのはなぜですか
私は単純なカーネル拡張機能を持っています:
私がコンパイルしてロードしているもの:
そして、kextstat リストに表示されます。
ただし、kernel.log (または system.log) には何もありません。printf() ステートメントが表示されるはずです。理由はありますか?
xcode - Xcode/Instruments で色分けされた XNU スレッド状態
私は、Apple Instruments ツールを使用してマルチスレッド アプリケーションの分析を行っています。ツールで色分けされたスレッドの状態を説明する適切なリソースを見つけようとしています。私は XNU Kernel のドキュメントや本を調べてきましたが、うまくいきませんでした。
「プリエンプテッド」モードと「スーパーバイザー」モードに対応する黄色と紫がたくさんあります (添付画像の右上のポップアップにフル カラー チャートが記載されています)。「実行中」の状態 (青色) とは対照的に、これらの状態で多くの時間を費やしていることを考えると、これらの状態が何を指しているのか、また、これらの状態で過ごす時間を最小限に抑えることが可能/望ましいかどうかを知ることに特に関心があります。 .
macos - プロセスがネットワークカーネル拡張でroot権限を持っているかどうかを判断するにはどうすればよいですか?
私はソケットフィルターkextを書いていますが、rootとして行われた接続はすべて無視したいと思います。OS X Lion以前は、次のコードは問題なく機能していました。
しかし、LionとMountain Lionを使用すると、is_root()
関数は常にtrueを返します。Snow Leopardでは、想像どおりに機能しました。
ソケットフィルターイベントハンドラー内で関数をテストした例を次に示します。
ただし、出力には常に「ルート」と表示されます。次に例を示します。
接続するアプリがTwitterである場合(PIDで確認)。Twitterは、rootではなく通常のユーザー権限で実行されます。
ソケット接続の背後にあるプロセスにroot権限があるかどうかを判断するためのより良い/正しい方法はありますか?