GitHub - tkmru/linux-insides-ja: Japanese version of linux-insides bookYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
eBPFに3日で入門した話 - CADDi Tech Blog
はじめに eBPF とはなにか ざっくり概要 「Packet Filter」なのに「Virtual Machine」? eBPFでなにができるか? カーネルイベントのフック ユーザーランドアプリケーションとのやりとり eBPFの主な用途 eBPFが注目される背景 eBPFの仕組み アーキテクチャと処理フロー カーネルモジュールとeBPFの違い eBPFプログラムの作り方 eBPFプログラムを作ってみる 環境の準備 Hello world もう少し複雑なサンプル その他のサンプル HTTPリクエストのダンプ TCP接続先の調査 tcplife dirtop filetop oomkill まとめ eBPFはなにに使えるか 参考サイト はじめに こんにちは、Platformチームの小森です。 eBPF (extended Berkley Packet Filter) について、2022年8月2
Rust for Linuxを手元で試す
RustをLinuxカーネルに組込みプロジェクト、Rust for Linuxが進行中です。 このプロジェクトはLinuxカーネル全体をRustで置き換えるわけではなく、第二言語としてRustを採用してデバイスドライバなどのモジュールを書くことができるようにしようというものです。 RustはOSのような低レイヤーソフトウェアを実装する言語として、C言語に代わる選択肢として注目されてきたわけですが、Linuxのような広く使われているシステムに採用されるとなればかなり熱いですね。 実際にLinuxのメインラインに取り入れられるにはまだまだ課題は多いものの、Linus氏を含むLinuxの開発者からのフィードバックも比較的ポジティブでこれからが注目されています。 そんなRust for Linuxを手元でビルドして動かしてみました。 一応、基本的な手順はレポジトリ内のドキュメントにまとまっているの
起動しているLinuxマシンに適応されているDevice Tree Source(dts)を取得する方法メモ - /home/tnishinaga/TechMEMO
Linux kernelが起動時に読み込んで使っているdevice treeをdts形式で確認する方法を毎回忘れるので備忘録として残します。 device treeを使っているアーキテクチャならどこでも使える方法のはず。 1. device-tree-compiler を入れる device treeはdtbの状態で置かれているので、デコンパイルしてdtsに戻すためにdevice-tree-compilerをインストールします。 sudo apt-get -y install device-tree-compiler 2. linux kernelが読み込んでいるdtbをデコンパイルしてdtsにする kernelが起動時に読み込んで使っているdtbは /sys/firmware/fdt にあるので、これをデコンパイルしてdtsに戻します。 /sys/firmware/fdt の読み込み権限
Linuxのドライバの初期化が呼ばれる流れ - Qiita
2017年も残るところ1ヶ月を切りました。いよいよですね、待ち遠しくなってきました、 $\textlarge{鏡音リン・レン誕生祭！}$ 10周年を迎えて記念のコンピアルバムCDもたくさん発表されたりと、ボーカロイド界隈の勢いは衰えません。そこ、ミクさんの存在が大きくてほかは影が薄いとか言わない。ぼくだってこんなにハマるとは思わなかったんです。10年前はマジメに技術的な話だけを追っていたはずなのに、どうしてこうなった。こんな地味なプログラム系記事を書くようなおっさんじゃなくて、リンちゃんの曲を作る超売れっ子ボカロPに生まれたかったです。 ・・・失礼しました・・・ 本当のはじめに Linuxのkernelにはじめて触ってみるきっかけになったのはドライバの組み込みや修正だ、という人が多いんじゃないかと思う。現代的なOSではやらなくてはいけないことは非常に多岐にわたるけど、そんな全体像のことはわ
第692回 sysfsやbpftoolを用いたeBPFの活用 | gihyo.jp
第688回と第690回では、カーネルのトレーシングツールとして注目されているeBPFを活用するためのツールとしてBCCを紹介しました。しかしながら、BCCだけがeBPFを扱えるツールというわけではありません。今回はツールなしに利用できるsysfsや、よりユーザーフレンドリーなトレーシングツールであるbpftoolを紹介します。 Python版BCCの問題点 これまで紹介していたBPF Compiler Collection（BCC）のツールはいずれもフロントエンドとしてPythonを使っていました。つまり利用者はまずPythonスクリプトを起動し、その中でeBPFのオブジェクトをコンパイルし、ロードすることでようやくトレースが始まっていたのです。 実行環境でBPFオブジェクトをビルドする必要があるこの方法にはいくつかの問題点が存在します。 実行環境にコンパイラをインストールする必要がある
第688回 eBPFのコンパイラーに対応したツールでさまざまな挙動を可視化する | gihyo.jp
実行中のシステムの挙動を詳細にトレースする仕組みは、特に「よくわからない問題」に遭遇している時に重要です。今回はLinux向けのトレーシングツールの本命とも言えるeBPFを利用した各種ツールを紹介します。 eBPFに関する記事が今回以降、数回にわたって解説されています。あわせてご覧ください。 第688回 eBPFのコンパイラーに対応したツールでさまざまな挙動を可視化する（今回の記事） 第690回 BCCでeBPFのコードを書いてみる 第692回 sysfsやbpftoolを用いたeBPFの活用 第694回 libbpfとclangでポータブルなBPF CO-REバイナリ作成 第695回 入門BPF CO-RE eBPFとBPF Compiler Collection 改めて言うまでもなく、Linuxカーネルもしくはカーネル上で動いている各種タスクのパフォーマンスや挙動を調べなくてはならない
Linux の挙動を変更する 4 つの方法
検証環境CentOS 8 で検証する。 ]# cat /etc/redhat-release CentOS Linux release 8.1.1911 (Core) ]# uname -a Linux localhost.localdomain 4.18.0-80.el8.x86_64 #1 SMP Tue Jun 4 09:19:46 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux カーネルコンフィグ異なるバイナリを作成するための設定。Linux は様々なハードウェアをサポートしており、また、機能もわんさかある。これらの機能をすべて実行バイナリに含めると、使ってない機能のせいでセキュリティリスクが無駄に高くなったりバイナリサイズがでかくなったり分岐処理が挟まって性能が落ちたりして都合が悪い。そこで、ソースコードレベルで機能の有効/無効を切り替えて専用のカ
組み込みLinuxデバイスドライバの作り方 (1) - Qiita
1回目: ビルド環境準備と、簡単なカーネルモジュールの作成 本連載について 組み込みLinuxのデバイスドライバをカーネルモジュールとして開発するためのHowTo記事です。本記事の内容は全てラズパイ(Raspberry Pi)上で動かせます。 Linuxデバドラ開発は最初の一歩が難しいと思います。資料も少なく、たいていの人はオライリー本に手を出して挫折すると思います。(僕がそうでした。。。) この記事では、「Linuxデバイスドライバプログラミング (平田 豊) 」の内容に沿って進めていこうと思います。この本は非常に分かりやすく良書だと思います。ただ、2008年発行と古いので、現在(2017年12月)の環境でも動くように、実際にRaspberry Piで動かしながら確認していこうと思います。(途中から、本の内容とは離れます) また、出来るだけ簡単にしたかったので、クロス開発環境は整えず、ラ
YoctoでLinuxカーネル触るときのTips - Qiita
ことあるごとに「Yoctoで取ってきたコードで開発しちゃダメ」とはいわれるものの、ビルド環境がある以上はソースを触りたいのが人情。 というわけでYoctoでLinuxカーネル触るときのTipsを記載してみる 以下ターゲットがi.MX6の環境について記載されているので、それ以外のターゲットでは適宜読み替えること。 最重要事項: gitリポジトリは作り直される 基本的にdo_unpackタスクが走ると、gitリポジトリごと一から作り直される。 そのためコード修正してgit commitして一安心、と思っていると泣きを見ることになる。 do_unpackはdo_cleansstateしたりレシピファイルを修正したりすると簡単に走ってしまうため要注意。 カーネルソースはどこにあるか 以下で確認可能 $ bitbake -e linux-imx | grep '^S=' S="/home/user/
第674回 カーネルのクラッシュ情報を解析する | gihyo.jp
第673回の「カーネルのクラッシュ情報を取得する」では、カーネルクラッシュ時に情報を収集する仕組みを有効化しました。得られた情報は活用しないと意味がありません。今回はその中身を解析する方法を紹介します。 デバッグパッケージのインストール 第673回では、意図的にシステムをクラッシュさせることで、dmesgとvmcoreを取得しました。カーネルが今際の際に次につながる情報を残してくれたのです。「しかしながらあのクラッシュが最後のpanicだとは思えない。もし、同じカーネルが続けて使われるとしたら、あのpanicの同類が、また世界のどこかへ現れてくるかもしれない……」 最初に行うべきなのは、前回紹介したように問題発生時のdmesgを読むことです。これである程度、状況の絞り込みは行えますし、運が良ければ原因がわかることもあります。しかしながら、dmesgだけだと「問題が起きた場所」はわかっても
perf, ftraceのしくみ - 睡分不足
Linuxのトレーサーであるperfやftraceのツールの使い方に関する情報は結構ありますが，構造に関してはあまり見つけられなかったため，ここに簡単に調べたことをまとめようかと思います．（ツールの使い方の説明はあんまりしないです．） この文章はLinux 4.15のソースに基づいています． 全体像 ftrace function trace tracepoint (static event) kprobe (dynamic event) その他のtracer trace-cmd perf PERF_TYPE_HARDWARE, HW_CACHE, RAW PERF_TYPE_SOFTWARE PERF_TYPE_TRACEPOINT PERF_TYPE_BREAKPOINT USDT (SDT Event) perf-tools perf ftrace straceとの比較 その他 pe
)
linux-4.4.1/container_of() - コグノスケ
説明† パス: linux-4.4.1/include/linux/kernel.h ポインタが指す構造体のメンバ、それを含む構造体へのポインタを返す。 例えば、 struct example { int mem_a; char mem_b; }; struct example hoge; という構造体があったとする。 int *mem_ptr = &hoge.mem_a; 上記のような、構造体のメンバへのポインタ mem_ptr しか 分からない状態から hoge へのポインタを得たいときに container_of を 使う。 struct example *ptr = container_of(mem_ptr, struct example, mem_a); すると ptr が指す先（hoge.mem_a）を含む構造体への ポインタ（&hoge）が得られる。 ↑ 引数† ptr 構造
QEMUのgdbserver機能でNetBSD kernelをデバッグする - Qiita
QEMUにはgdbserver1が内蔵されており、ホストのgdbからtcp越しにゲストOSのカーネルをデバッグすることができます。この記事は上のGIF動画のようにNetBSD kernelのデバッグを行うHowtoです。 （VMWareでも同じことができるらしいです。WindowsならVirtualBox+VBoxGDBでもできるらしいです。が、私は日常的にNetBSD仮想マシンを使っている訳では無いので、気軽に環境構築・撤去ができるQEMUが好きです。libvertでもできるらしいのでそのうちやってみようと思ってます。） 注意事項 ホストOSはLinux (Ubuntu 18.04), macOS (Mojave 10.14.3) で検証済みです。Windowsや他のOSでの動作報告お待ちしております！ ゲストOSは NetBSD - 8.0-amd64 で検証済みです。 i386の場合
TIL: eBPFは素晴らしい
Filip Nikolovskiのブログより。 仕事でマイクロ・サービスのトレースや可観測性(Observability)について仕事で調べていた時に、Pixielabsに出くわしました。このツールは、アプリの内部にインスツルメンテーション(計器一式)や特別なコードを入れなくても、アプリのトラブルシューティングを即座に行えると宣伝していて、私には✨魔法✨のように聞こえました。だから当然、この技術が機能する理由について、もう少し詳しく知りたいと思い、サイトをスクロールしていくと、「インスツルメンテーションなし」のセクションの下に、この頭文字をとったeBPFがありました。 インターネットでさらに調べて、デザインペーパーを読んで、いくつかのビデオを見た後、この技術が私の目に留まったと言っても過言ではないので、メモを書きたいと思いました。この投稿があなたの興味をさらに刺激することを願っています。
組み込みLinuxの起動シーケンスを理解し、自社開発のLinuxアプリケーションをシステムへ統合する | APS｜組み込み業界専門メディア
組み込みLinuxの魅力は、オープン・コミュニティから収集した多彩なコンポーネントと自社開発のコンポーネントを自由自在に組み合わせ、サービスを手早く構築し、これまでに無かった価値を創造できることです。今回の初心者講座ではLinuxディストリビューションの起動シーケンスを例に、Linuxディストリビューションにはどういったコンポーネントが含まれているのか、Linux上にて各コンポーネントはどのように連携しているのかについて解説いたします。また、こうしたLinuxのコンポーネント上で実行できるアプリケーションの開発方法を記事後半で解説。開発するPC（ex. Intel CPU）と異なるCPUアーキテクチャのターゲットデバイス（ex. 64bit Arm）を扱うためのクロスプラットフォーム開発の導入部を紹介いたします。是非、最後までお楽しみください。 8本すべて無料！組み込みLinuxウェビナー
めくるめくLinuxカーネルじゃないLinux実装の世界 - Qiita
EDIT^7: blink と box86、FEX。 EDIT^6: Unikraft 。 EDIT^5: Tilck 。 EDIT^4: コメント。gVisor はすっかり忘れていました！Linuxを拡張するためにLinuxを実装した良い例だと思います。LINE有りましたね。。 SF.netのCVSはもう死んでしまったので除外にしました。。 OSvのバイナリ互換 はPIEであることが要求なので。。といっても世間的にはもうLinux = Debian/Ubuntu で良いですかね。。表現を調整しました。 EDIT^3: Noah忘れてた！ EDIT^2: Cygwinは 下書き段階で削ってしまった 。。 qemuを移植したとき に互換性がイマイチだったので。。特殊fdやprocfsの充実ぶりとかを考えると "かなりLinux" と言って良いとは思うけど、 mmap 等でLinuxとWind
Linux メモリ断片化 (外部フラグメンテーション) の概要と解消方法 - Qiita
■ 記事概要 Linux OS におけるメモリ断片化 1 ( 以降、断片化 ) について、調査したことのまとめ。 ■ 要約 断片化していると、空きメモリが十分あるにも関わらず、メモリ確保に失敗することがある。 断片化の影響を受けるのは、DMA ( Direct Memory Access ) のように物理メモリ領域を直接参照する必要があるもの ( 仮想メモリを使える場合は、物理メモリ領域が連続している必要がないため影響なし )。 断片化のレベルは /proc/buddyinfo や /sys/kernel/debug/extfrag/unusable_index から確認可能。 明示的に断片化を解消する方法は、OS 再起動と、# echo 1 > /proc/sys/vm/compact_memory がある。 ■ 物理メモリ領域について 断片化の話の前に物理メモリ領域について整理する。
Linux Kernel: __initマクロ、__exitマクロの役割(メモリの有効利用)
Linux Kernel: __initマクロ、__exitマクロの役割(メモリの有効利用) by nao · 公開済み 2019年4月29日 · 更新済み 2020年12月25日 __initマクロ、__exitマクロが使われるケース 一般的に、__initマクロはKernelモジュールの初期化時、__exitマクロはKernelモジュールの終了時に付与します。以下の例では、初期化関数がdebimate_init()、終了関数がdebimate_exit()で、それぞれにマクロを付与しています。 static int __init debimate_init(void) { int result = 0; struct device *debimate_dev = NULL; pr_info(KERN_INFO "START: %s\n", __func__); /* メジャー番号の動的
KernelAddressSanitizer (KASan) による Linux のメモリ破壊問題の検出 - Qiita
この記事は Fujitsu extended Advent Calendar 2016 の 25 日目の記事です。 記事は全て個人の見解です。会社・組織を代表するものではありません。 この記事では Linux カーネルの機能の一つである、KernelAddressSanitizer (KASan) の紹介、および、機能を実際に使った結果を紹介します。 はじめに カーネルやモジュールにおいて、厄介なバグの一つにメモリ破壊があります。メモリ破壊が厄介なのは、破壊されたことはログやメモリダンプ等からわかりますが、破壊したことの証拠が残らないケースが殆どなことです。なので、ひたすらソース解析や、printkやトレースを仕込んでバグを探す・・・という苦行を繰り返す必要があります。 KASan は Linux 4.0 から導入されており、厄介なメモリ破壊につながる以下のバグを検出する手助けをしてくれま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
