>>349
そこまでわかっているなら話は早い。
YESかNOかでいえばYES。lintやccを黙らせるため。

でも、その部分だけを取り出してみればlint等を黙らせるためというのはわかるけど
よくよく全体を見て考えると、他のコンパイラでは使えない({})を使ってるわけで
基本gcc前提だよな。
そもそも、その({})(が展開された部分)について、lintは盛大に文句を言うのではなかろうか。

そう考えるとやっぱり、最適化の過程のコード削除を効かせやすくするためだと思うんだが

割り込みハンドラからドライバに処理振るまでってどの辺よめばわかるかな

最適化切るとビルドできないのはびっくりした。
デバッガに優しいビルドをしようと-Osも切ったらビルドエラー。
最適化で消えることが前提のコードを使ったマクロとかがあって、
それが悪さしてた。

最適化有効でソース行の実行順序がひっくり返った結果、
追いかけた時に正常なところが異常に見えたりしてハマって泣いたので
やってみたのだけど、コンパイラ使いこなしてるなーとチョト感動した。

タイマはクロックを使うとは限らない
選んだ周波数はクロックに従ってるものにしか影響しない

>>365
積んでる石ならな

>>368
カーネルを書き換えない限り、その方法では他プロセスの書き込みは検出できない

一応tmpfsでも問題なく使えるみたい。
ただ、書くつもりで開いてたのが閉じたか、というのがイベント発生条件なので、mmapしたかとか、本当に書いたかは関係ない。
なので片方はデーモン、もう片方は何かイベントがあったら共有メモリに書き込んで終了、みたいな構成なら使えるけど、やっぱり限定的だな＞使い方

まあ真面目にIPCしなさいってことだ。

カーネルじゃなさそうだが、動けばいいのならmwriteの前後でchmod自動で呼ぶようにすればいいんじゃないか。

原因は知らんけどmwriteがポリシとして特定のグループや許可で動くのが前提になってて、自分が適切なグループに入ってないとか。

>>381
じゃあudevじゃない？
認識した際に飛ばしてくるイベントの内容が変わったとかでudevdが適切に反応できてないとか。

>>384
マルチスレッドに対応するようにプログラミングしているのに、
95%しかCPUを使えないのは資源の競合などで、
効率的に動作できていないものと考えられます。

その状況でさらにタスクを増やしても、
競合が酷くなるだけで無意味です。

2つのCPUを効率的に使いたいなら、
コードの見直しが必要です。

その5%は天使の分け前なんですよ

>>384
あまり有用なレスはつけられないと思うが、
まず、実行時間、CPU時間がどれだけ伸びたか time でも貼ってくれよ。

我らがアイドル mkosakiたんはどこにいってしもうたん？

いつでもみんなの心のなかにいるよ
。

概念的な存在になって世界中のカーネルの中に分散したんだ！
そして永久にデバッグを・・・

http://mkosaki.blog46.fc2.com/blog-entry-1178.html

「ところでですね。わたし最近USに引っ越したんですよ。」

F社は辞めたのかな？

やめてないよ

がちゃぴんは ―２度とユーザー空間には戻れなかった…。
赤帽とF2の中間の生命体となり
永遠にカーネル空間をさまようのだ。
そしてglibcは市ね！と思っても直らないので、
―そのうちがちゃぴんは考えるのをやめた。

時々再起動しろってことか、面倒くさいな。