「主要なところだけ」って言いかたはしないけど。一時期は読んでいたけど、最近は忙しくて全部は読んでいないですね。今僕がやっている仕事は、コアのどこかを弄っている訳ではないので。どこかのタイミングでキャッチアップは必要になるかも。バグとして直す、みたいなのがありましたよね。さんに教えてもらった現象があって。ハングしていたものが、ハングしなくなったんだから。僕も当時その理屈を使って説得したはず。場合はどこにもドキュメントで保証されてない挙動についてオレの思ってた動きと違うからカーネル変えろとか言ってくるので色々言われました。使ってるから困るとか。テストコードでしょう。特殊なエラーコードを返していた。側ではそれを受けてシステムコールが失敗したら例外を投げる想定だったという話になって。側でも例外があがって嬉しいかというと、全く嬉しくない。代表作たくさんあるじゃないですか。仕様からは若干逸脱した作りになっていて。サーバやるときとかそれでは全然足りないから、みなさんカーネルパラメータをそれよりたくさんに変更してるんですよ。とってそれを渡すことをやっている。するというロジックを入れた方がいらっしゃいまして。正しくないコードを見つけたときに、ライブラリの側でどう処理するべきかという議論が最近ありますよね。最近の流れとして「セキュリティ的な意味で悪用されたら問答無用で処理を中断する」という方針がある。書かせる事ができてしまう。側でもこの理由があってチェックを入れたんですよね。「どのファイルディスクプリタにビットがたっている」なんて制御できない12から、現実問題怪しげな事はどれくらいできるのか。任意のメモリ領域に書き込む事が出来るというのは理解できるけど、じゃあそれで具体的にどう攻撃できるのか。