自転車の話です
久々の好天 + 体調も整ったので自転車 (Domane SLR) でお出かけ
台風が過ぎて湿気が吹き飛んだのか、遠方の山まではっきりみえる澄んだ秋晴れになった。那須高原〜国道294号線〜大田原を巡った。
走行距離 90km と獲得標高 687m
続きを読むTHE DESIGN OF THE UNIX OPERATING SYSTEM - Maurice J. Bach 📘
本棚を整頓していたら 『THE DESIGN OF THE UNIX OPERATING SYSTEM - Maurice J. Bach』 が出てきた
1986年出版である。古典。
Classic description of the internal algorithms and the structures that form the basis of the UNIX operating system and their relationship to programmer interface. The leading selling UNIX internals book on the market.
UNIX オペレーティングシステムの基盤となる内部アルゴリズムや構造体、およびそれらとプログラマのインターフェースとの関係についての古典的な記述。市場で最も売れているUNIXインターナルの本です。 ( DeepL翻訳 )
表紙のデザインが気に入っている
2013年にペーパーバック版を買っていて、その後、どうしてもハードカバー版が欲しくなって買い足したものだ。表紙がかっこいいから飾りたかった! ただそれだけのために!
ペーパーバック版はこんなん。(2013年に撮影)
ペーパーバック版は書き込みをしつつ読み込んだ。本棚には見当たらない。行方不明になってしまった。
肝心の中身の話。
UNIX System V Release 2 をベースにしているらしいが、図解や擬似コードを添えて説明が続く。
システムコールを呼び出す C のサンプルコードも出てくる。
擬似コード =骨格だけに削ぎ落として Design =「設計」にフォーカスした教科書と言えるんだろうか。擬似コードのアルゴリズムは素朴に書かれている。
実際の 「実装」= ソースコードには些末な処理が含まれたり、変数、型や関数名などにも気を取られたりして、本質的な理解の妨げることもあるからなぁ
古い本だから 令和のこの時代に読む必要ないか ... というとそんなこともない
プロセスのモデルやシステムコールのインタフェースは 現代の *nix と同じだ
そういえば、最近、デバンドページングとコピーオンライトを調べ直す機会があった
この本にも載っている
System V Release 2は1984年4月にリリースされた[1]。シェル機能とSVIDが導入されている。新たなカーネル機能として、ファイルロック、デマンドページング、コピーオンライトが導入された[3]。
2013年当時、この本を読んだことで Linux カーネルを(ちょっとだけ)理解する基礎体力づくりにはなったよなぁと思い返していた
CAT EYE バーエンドミラーを付ける 🚴♂️
自転車のネタです
イントロダクション
自転車が増えたので周辺パーツをぽちぽち集めてる
CAT EYE のバーエンドミラーを購入した 。以前から使っていたミラーが Amazon で見つからないので、代わりにほぼ同じ形状のを選んだ。
取り付けのイメージ
補助ミラーがあることで安全確認はぐっと楽になる。真後ろが楽に見れて走行中の安心感が全然違う。ロードバイク走行中に首をぐいっと曲げて後ろを見るのはちょいと面倒だし 安定感を損ねやすくバランスを崩して危険なこともある。
100km を超えるようなロングライドにもなると、補助ミラーがあると無いとでは疲労感にはっきり差がでてる
Garmin Varia と併用
Garmin Varia も付けているので、Varia センサーが反応したら「ミラーで後ろをみて車種や距離感を掴む」という併用をしている。バイクだったらあんまり気にしない、大型車だったら脇に避けたるのも検討する、道が狭くて追い抜けずにいるような車がいる場合は譲るとしてマナー向上 🍵
信号待ちで後続車がウィンカー出しているか、チラっと見るのも役立つ
見た目は ..
ただ、まぁ、正直なところ、ロードバイクの外観を損なうのは否めない。そういう商品レビューも見かけるし、同意はする。 スマートさは損なってもよくて、安心・安全に走れる方がいいなぁという人にはオススメ
注意書き
あくまで補助のミラーです。右斜め後ろが死角になり、追い抜きざまの車が見えないことがあります。ピっと後ろを向いての後方確認もしましょう。
風が強い日や交通量の多い道路なんかだと、死角に入った車の音が聞こえなくて 気がつかないことあるんだよなぁ。不意を突かれて怖いことがよくある
Trek Emonda SL のシートマストキャップのクランプを交換する 🚴♂️
自転車のネタです
イントロダクション
先日、Emonda SL で使っていたシートマストキャップ(カーボン) のクランプのネジが切れた + ネジ穴をナメてしまったので、34.9mm のクランプと交換した。
白いのが古いクランプ。銀色のが新しくつけたクランプ。古いのは えいやーっと引っ張ったら外れた。接着剤で固定されてたぽい。
色は変えたくなかったが、オンラインでは見つからなかった。
なんでネジ切れたの?
オーバートルクだったのかな。Bontrager のトルクレンチ ( 最大 5Nm ) で扱っていたのだけどネジが切れてしまった。
トルクレンチは5年前から使っているものなので、不調になってしまったか、あるいは、ネジが寿命だったのかなぁ
ちなみに Emonda を買った時にサービスで付属してきたものである
シートマストキャップ？
Trek 専用パーツで、いわゆるサドルポストにあたる
新品だと 18,000 円 する! 高い ！さらにホワイトカラーは古いモデルで 現在、新品では手に入らない。メルカリやヤフオクでも稀にしか見かけない。
クランプは数百円で手に入った。これで何とかなるなら お財布にとっても優しい 💴
ロードバイクのハイグレードモデルに憧れはあるが 細かいパーツが専用品になってロックインされるし、メンテナンスも高価になりがちで、厳しいなぁと思う
謝辞
クランプは下記のブログで交換できることを知ってチャレンジしてみました。 大変ありがたい!
Linux: mmap(2) したメモリに書き込みした際の Copy On Wirte を観察する
イントロ
ペパボ社内 Slack で Linux の CoW = Copy On Write について、 id:ryuichi1208 id:udzura とディスカッションして盛り上がっていた。カーネル内で CoW を処理する関数を追えないか? という話があがったので、調べてみた次第。
( なぜ CoW の話が出てきたのか / どんなことをディスカッションしてたのかは id:ryuichi1208 がまとめくれるかも? )
結論
CoW を観察するには do_wp_pageを観察するといいみたい
( いつもお世話になっております )
do_wp_page のソース
https://elixir.bootlin.com/linux/v5.11.22/source/mm/memory.c#L3085
検証環境
Vagrant で用意した
$script = <<-SCRIPT sudo apt-get update && apt-get install -y build-essential bpftrace bpfcc-tools linux-headers-$(uname -r) SCRIPT Vagrant.configure("2") do |config| config.vm.box = "bento/ubuntu-21.04" config.vm.provision "shell", inline: $script end
検証コード
以下の検証コードを用意した
- 親プロセスで mmap(2) して minor page fault を起こしておく
- 親プロセスが fork(2) する
- 子プロセスが 1 のメモリに書き込みして minor page fault を起こす
- カーネル内で do_wp_page で CoW が実行される
を期待する動作とする。
#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <unistd.h> #include <sys/mman.h> #include <sys/types.h> #include <sys/wait.h> int main(int argc, char *argv[]) { /* CoW を起こしたいページ数 */ int pages = 100; /* getconf PAGESIZE */ size_t page_size = 4096; /* 観察しやすいようにアドレスを固定する */ char *p1 = (char*)mmap((void *)0x100000000000, page_size * pages, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0); if (p1 == MAP_FAILED) { perror("failed to mmap"); exit(1); } printf("mmap: %p\n", p1); /* 親プロセス: minor page fault */ for (int i = 0; i < pages; i++) { p1[i * page_size] = 'p'; } pid_t pid = fork(); if (pid == -1) { perror("failed to fork"); exit(1); } else if (pid == 0) { printf("child pid:%d\n", getpid()); /* 子プロセス: minor page fault -> cow -> do_wp_page */ for (int i = 0; i < pages; i++) { printf("cow address: %p\n", &p1[i * page_size]); p1[i * page_size] = 'c'; sleep(1); } } else { printf("parent pid:%d\n", getpid()); waitpid(pid, NULL, 0); } }
観察
bpftrace で do_wp_page をトレースする
kprobe:do_wp_page /comm == "cow"/ { printf("do_wp_page > pid:%d comm:%s address:%p\n", pid, comm, ((struct vm_fault *)arg0)->address) }
- その他プロセスの CoW が邪魔しないよう
commでフィルタする - struct vm_fault の address で fault を起こした仮想アドレスが取り出せる
- printf して検証コードと付き合わせて確認する
単に do_wp_page が呼び出されているかどうかだけ確かめるなら perf-tools なんかでも OK
実験
こんな感じで観察できました。とりあえず このエントリはここまで
perf-tools の場合
perf-tools の functrace だと ↓ みたいにトレースできる
$ sudo ./bin/functrace do_wp_page
cow-25935 [000] .... 24930.105521: do_wp_page <-handle_pte_fault
cow-25935 [000] .... 24930.105522: do_wp_page <-handle_pte_fault
cow-25935 [000] .... 24930.105534: do_wp_page <-handle_pte_fault
cow-25935 [000] .... 24931.122937: do_wp_page <-handle_pte_fault
cow-25935 [000] .... 24932.158144: do_wp_page <-handle_pte_fault
cow-25935 [000] .... 24933.165625: do_wp_page <-handle_pte_fault
cow-25935 [000] .... 24934.167118: do_wp_page <-handle_pte_fault
cow-25935 [000] .... 24935.168714: do_wp_page <-handle_pte_fault
cow-25935 [000] .... 24936.177183: do_wp_page <-handle_pte_fault
その他
最初は do_cow_fault() を調べていたのだが、こちらは anonymous ページでなく file backed な ページの CoW を処理する関数ぽい? (まだ調べてないので宿題)
memory.c - mm/memory.c - Linux source code (v5.11.22) - Bootlin
名前にまんま cow が含まれているので、「Copy on Write 処理するのは これなのだろう」と思い込んでしまった。検証コードが期待したように動作せずハマってしまった。
参考
Domane SLR 2017 🚴♂️
お盆期間に Domane SLR 2017年モデルを手に入れた
2017年のモデルなのでちょっと古いモデル。
新しい相棒がきた🚴♂️
— ito hiroya (@hiboma) 2021年8月17日
ペダルがない+雨なので 試走はまだお預け pic.twitter.com/3BztaegxSe
年数は経っているが傷は少ないので、フレームはまだまだ保つかと期待。数年はがんばってもらいたい
続きを読むLinux: /usr/share/doc/cron/THANKS
Ubuntu (Xenial) の deb パッケージについて調べていたら、たまたま /usr/share/doc/cron/THANKS なるドキュメントを見つけた
ubuntu@hiboma-test:~$ ls -hal /usr/share/doc/cron/THANKS -rw-r--r-- 1 root root 1.6K Sep 1 1994 /usr/share/doc/cron/THANKS
/usr/share/doc/cron/THANKS
中身は以下の通り。 15 January 1990 に書かれたものかな?
ubuntu@hiboma-test:~$ cat /usr/share/doc/cron/THANKS
15 January 1990
Paul Vixie
Many people have contributed to cron. Many more than I can remember, in fact.
Rich Salz and Carl Gutekunst were each of enormous help to me in V1; Carl for
helping me understand UNIX well enough to write it, and Rich for helping me
get the features right.
John Gilmore wrote me a wonderful review of V2, which took me a whole year to
answer even though it made me clean up some really awful things in the code.
(According to John the most awful things are still in here, of course.)
Paul Close made a suggestion which led to /etc/crond.pid and the mutex locking
on it. Kevin Braunsdorf of Purdue made a suggestion that led to @reboot and
its brothers and sisters; he also sent some diffs that lead cron toward compil-
ability with System V, though without at(1) capabilities, this cron isn't going
to be that useful on System V. Bob Alverson fixed a silly bug in the line
number counting. Brian Reid made suggestions which led to the run queue and
the source-file labelling in installed crontabs.
Scott Narveson ported V2 to a Sequent, and sent in the most useful single batch
of diffs I got from anybody. Changes attributable to Scott are:
-> sendmail won't time out if the command is slow to generate output
-> day-of-week names aren't off by one anymore
-> crontab says the right thing if you do something you shouldn't do
-> crontab(5) man page is longer and more informative
-> misc changes related to the side effects of fclose()
-> Sequent "universe" support added (may also help on Pyramids)
-> null pw_shell is dealt with now; default is /bin/sh
以下は DeepL の翻訳をベースに、人名だけアルファベットに置換した内容です
1990年1月15日
Paul Vixie
多くの人がcronに貢献してきました。 実際のところ、私が覚えている以上に多くの人がいます。
Rich Salz と Carl Gutekunst は、それぞれV1のときに大変お世話になりました。
Carl は私がUNIXを理解して書くのに十分な手助けをしてくれ、Rich は私が機能を正しく理解するのを助けてくれました。
機能を正しく理解する手助けをしてくれました。
John Gilmore はV2の素晴らしいレビューを書いてくれましたが、それに答えるのに1年もかかってしまいました。
(Johnによると、最もひどいものは、もちろんまだここにあるそうです。)
Paul Closeは、/etc/crond.pidとそれにロックするミューテックスにつながる提案をしました。
につながりました。 PurdueのKevin Braunsdorfは、@rebootとその兄弟姉妹につながる提案をしました。
彼はまた、cronがSystem Vでコンパイルできるようにするためのいくつかの差分を送りました。
しかし、at(1) 機能がなければ、この cron は System V でそれほど有用ではないでしょう。
Bob Alverson は、行数カウントの愚かなバグを修正しました。
行数カウントの愚かなバグを修正しました。 Brian Reid は、インストールされたファイルのランキューとソースファイルのラベル付けにつながる提案をしました。
インストールされた crontabs のソースファイルのラベル付けにつながる提案をしました。
Scott Narveson は V2 を Sequent に移植し、私が誰からも得られなかった最も有用な単一の diff バッチを送ってくれました。
差分を送ってきてくれました。 Scott による変更点は以下の通りです。
-> コマンドの出力が遅くても sendmail がタイムアウトしない。
-> Day-of-week の名前が1つずれないようになりました。
-> crontab は、やってはいけないことをやった場合に正しいことを言うようになりました。
-> crontab(5)のマニュアルページがより長く、より情報的になりました。
-> fclose() の副作用に関するその他の変更。
-> Sequent "universe" のサポートが追加されました (Pyramids にも役立つかもしれません)
-> null pw_shell に対応しました。
Paul Vixie さんとは?
ポール・ヴィクシー(Paul Vixie)はいくつものRFCと良く知られたUNIXプログラム、SENDS、proxynet、rttyおよびVixie cronといったプログラムの作者。
作者からの謝辞なのか〜
もう少し歴史を追ってみたいけど 時間が溶けそうで こんなもんで終わり
