>>752
じゃなくて、commitされるものはどれもテストされるべき
って言いたいんじゃない？

テストコードが無いのはレガシーコードだと言いたいのでした。

ただ、ドライバとかはむずかしいのかもとは思った。

>>754
LKML読んでて、テストコードでなんとかなりそうな問題って少ないんだが、具体的にはどうよう状況を想定してる？

例をあげる。
定期的にregressionする問題児機能として、cpu-hotplug, memory-hotplugがあるが、これは明らかに
開発者がテストできないのが問題。
かつ、CPUやメモリを挿抜できるマシンを見たこと無いと何に気をつけないといけないか、普通は一生知る機会がない。
カーネル内に普通にif 文入ってりゃカーネル勉強してれば自然と身につくけど、速度の兼ね合いで巧妙に if文が
入らないようにしてあるケースが多いので、コードを読んでいてもまず理解できん。

個人的な経験でいうと、ユニットテストが有効なのはアプリケーションレイヤだよ。テストってのは自分のもってる仮定が真か
否かを確認する作業なので、よく分からないハードの互換性のための機能とか、よく分からないアプリの互換性のための
機能とかは、テストできない。

それに加えて、性能のために、無理矢理ロックレスにしてる部分ってユニットテストすると、failureするよね。
でも人間は気づかないのでOK理論でまかり通ってる。
この「人間は気づかないはず」ってのはかなり曖昧な根拠なので、すごく予想外のワークロードで破綻したりする。
テスト不足が原因じゃなくて設計時の分析不足が根本なので、テストじゃ品質は上がらない

ちょっと、違う河岸の人の意見が聞きたくなったので、燃料投下ですよ

とうっかり書いてしまったがそんなへんてこなmockを書くのは極めて難しいな

ドライバ類って共通レイヤでのユニットテストがしやすそうなイメージあるけどなぁ。
ハードウェアエミュレータがあれば更に良し。

具体的にはどうやってテストするの？
エミュレータなんかかました途端に、それは「エミュレータに対するテスト」
でしかなくなるし、ってかこの世のありとあらゆるデバイスの挙動の
あらゆるケースを実機通り（実機のバグ・不具合含めて）に正確にテスト
できるエミュレータとか、ちょっとありそうにない気がするが。

テストってそんなもんな気がするけど???

今時のx86って分岐ヒント・プリフィックスがあるんだね

今のgccは分岐prefixは生成しないと思うが。今のCPUの実装でいうと勝手に命令はprefetchされてるんだけど、
ジャンプ命令は飛び先が命令をfetch終わるまで分からない（当たり前だ）、だから、ジャンプしないほうに可能性が
高い処理を入れておくのが賢い。
確率が半々のif文だったら、飛び先を近くにしておくと、ちょっと先fetchでtakenもnot takenもフェッチされるので
お得だけど、確率が90%の時は残り10%はすんげえ遠くに追いやった方がお得。
よってunlikelyで通らないとヒントづけされたブロックは関数の最後の方に寄せられる。likelyはその逆。

確か今時のプロセッサの分岐予測は
初見の分岐を見たら、その分岐が手前方向だったら分岐すると予測し
先方向だったら分岐しないと予測すると思ったけど。

理由はもちろん、ループというのがそういう形に作られているため。
(先方向の理由は知らないが、たぶん統計的なものだろう)

で、当然、最適化コンパイラは、
それ(分岐頻度の想定)にあわせた分岐/非分岐のブロック配置をする。

>>772
実行プロファイルとか取ってるのかと思ったら、あんま賢くないんだね。

>>773
プロファイルとってるけど、数に限りがあるから、テーブルにのってないジャンプについては
typicalなコンパイラのクセからポリシーを決めるんだわさ

「プロファイルをとっている」のはCPUだぞ？
理解した上で書いてる？
そりゃ、カーネルスレでハードの話題はスレ違いだが、話の流れってものがあるから。

このへんみれば、おおよその技術的なことはわかるんじゃないかね。
http://ja.wikipedia.org/wiki/%E5%88%86%E5%B2%90%E4%BA%88%E6%B8%AC

>>779
型チェックが欲しいときと要らん時があるからだろ。

っカーネルソース

流れ出したみたい