Linuxのpipeの実装を見てみる - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
Unix V6のpipe()と比べてLinuxのpipe()どう実装しているんですかねーなんて話を最近したのでちょっと見比べてみた。 V6のpipeははじめてのOSコードリーディング 読書会 (15)でやったところなんだけど、俺は風邪ひいて家で引きこもってたので・・・ V6のpipeの挙動は大体こんな感じ。 pipeはルートディスクのストレージ領域を4096B（8ブロック）使用し実現する 4KBのデータ領域はひとつのファイルとして扱われる（inodeが割り当てられる） オンメモリではなくてストレージを経由するが、バッファサイズが小さいのでブロックデバイスのバッファキャッシュが効きやすいようになっている pipeの受け手がデータを読みだす前に他の優先度の高いプロセスがブロックデバイスを使用するとキャッシュが効かなくなる可能性あり でも、データはストレージに書かれているので内容が壊れると言った
Linuxのネットワークインターフェース名って何を基準に決めてるのかを確認してみる - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
そういえば何を基準にインターフェース名を決めてんだっけ？というのを確認してみる。名前をつけているのはudevというか今ならsystemdですかね。とにかくそのルールが知りたかったのです。 うちのデスクトップのイーサネットカードだとこんな感じのインターフェース名になっている。 masami@saga:~$ ip addr 2: enp101s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 そこでググってみるとArch LinuxのMLからudev-builtin-net_id.cというものに辿り着く。 これがインターフェース名を決めているコードっぽいけど、コメントにルールが書かれているのでそちらを見てみると以下のような記述が。 * Two chara
libvirtdがネットワーク設定にebtablesを使うようになってたのでlibvirtのネットワークが起動してなかった - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
今回のめもはArch Linux以外だと多分関係ないかも。パッケージの依存関係でebtablesが必須になっていれば多分問題無いはず。 仮想環境でも立ち上げようと思ってvirsh start ~なんてやったら↓のようなエラーが。 virsh Requested operation is not valid: network 'default' is not active とりあえず確認をしてみるとホントにinactiveに。 masami@saga:~$ sudo virsh net-list --all Name State Autostart Persistent ---------------------------------------------------------- default inactive yes yes こんなのは昔もあったなーと思いつつその時の手順を実行して
ext4：ディスクレイアウト調査中めも1 - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
何周遅れだよ！って気もするけどext4のディスク上のレイアウトを調べる。現状調べたのはファイルのinodeにたどり着くとこまでで、ファイルのデータにアクセスするところまではできてない。。。 基本的にはext4のwikiにあるExt4_Disk_Layoutのページを参考に。 テスト用に以下のようにディスクイメージを作り、1ファイルほど置いておく。 $ dd if=/dev/zero of=ext4.img bs=1M count=1024 $ mkfs.ext4 ./ext4.img ファイルの内容はこんな感じで。 #!/bin/bash for i in {1..16} do echo "abcdefgh" >> test.txt done そうしたらhexdumpでダンプを採ってあとはdebugfsコマンドや、自分でコードを書いたりしながら資料と見比べる。 まずは最初にディスクレイアウ
OSがどんなハイパーバイザー/コンテナ上で動いているか確認するツールのコードを読んだ - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
githubのTrendingと見ていてOSがどんなハイパーバイバー上で動いているか確認できるツールslabbed-or-notがあったので見てみた。 README.mdによると現状対応しているハイパーバイザーはXen、VMware、Hyper-V、KVM、bhyveに対応している。コンテナ型のOpenVZにも対応しているけど、LXCはまだ未対応だけど作者さん対応したいと思っているようなのでそのうち対応されるかも。 そして、一番興味があるのはどうやって判別しているのかというところなのでそこを見てみる。 判別はまず大きく２種類でハイパーバイザー型かコンテナ型かの判定をする。 コードだと下のような感じでチェック用の関数ポインタ等を登録した構造体を登録する。 struct test_impl *hv_test_impls[] = { &xen_impl, &vmware_impl, &hyper
Linuxカーネルで見たc言語の小技：BUILD_BUG_ONマクロ - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
LinuxカーネルにあるBUILD_BUG_ONマクロ。名前からやりたいことは十分に分かるんだけど、これはどういう仕組みなのかというところ。 使っている例としてarch/x86/kernel/head64.cにあるx86_64_start_kernel()を見てみるとこんな感じ。 140 asmlinkage void __init x86_64_start_kernel(char * real_mode_data) 141 { 142 int i; 143 144 /* 145 * Build-time sanity checks on the kernel image and module 146 * area mappings. (these are purely build-time and produce no code) 147 */ 148 BUILD_BUG_ON(MODU
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
