NetBSD その24

**名無しさん＠お腹いっぱい。** · 2008/05/21(水) 02:11:13

``Of course it runs NetBSD.''
＿ノ⌒ゝ
＼　　´-ヽ
　＼ノ⌒ヽ
　NetBSD
　　　　＼
ttp://www.netbsd.org/

前スレ
NetBSD その23
http://pc11.2ch.net/test/read.cgi/unix/1203467127/l50

**名無しさん＠お腹いっぱい。** · 2008/08/07(木) 09:22:21

>>668
だから、NetBSDの「良さ」である移植性をまず第一に宣伝すべきだと思ってるの。

**名無しさん＠お腹いっぱい。** · 2008/08/07(木) 09:23:07

IBMってまだPC作ってるっけ？
MSならわからんでもないが。

**名無しさん＠お腹いっぱい。** · 2008/08/07(木) 09:25:54

移植性をありがたがるのはembeddedな連中ばかりで、
そこを宣伝して発展してもWindowsの対抗馬になんざならない罠。
ふつーのユーザーは安くて性能出ればCPUなんてカンケーねーんだよ。

**名無しさん＠お腹いっぱい。** · 2008/08/07(木) 09:54:38

>>670も一つや二つなんかのハードに移植作業してみ。
簡単に動かせたところで使う人間がいなきゃ意味ねー
って実感できるから。

移植性っつっても楽なのはデバドラだけで、新しいCPUをサポートしようと思ったら
必要なMDフックの数がかなり増えてるし、toolchainもメンテしないといけないし、
かなりハードル高いよ。実際sh5以降新しいCPU増えてないし。

**名無しさん＠お腹いっぱい。** · 2008/08/07(木) 10:21:31

>>669
それはないな。Linux でしか動かないのがあって一時的にってんならともかく。
MS-Win は（嫌いだけど）一応独自性のある部分はあるし。Linux は、
仕様的には Unix なぞってるだけ。

**名無しさん＠お腹いっぱい。** · 2008/08/07(木) 10:26:42

くだらない質問ですが、お願いします。

pkgsrcのコンパイルで生成されるオブジェクトって結構容量
食いますよね…。特に内蔵ドライブの制約のある古めのノートなんかだと
顕著で。ノートの内蔵ドライブを換装する手もありますが、値段がつりあわない
面があるので躊躇してしまいます。

そこで、例えば対策として、ソースツリーは各ノートなりでバラバラに更新するわけには
当然いかないので、ネットワーク上（NFS）の別のマシンで管理するとして、
問題は生成されるオブジェクトをどうするか、ですよね。

１）生成されたオブジェクトが収まりきるようあらかじめ考えてパーティションを切っておく
２）そもそもオブジェクト自体も例えば/export/NetBSD-build/pkgsrc以下にマウントし、
NFSマシン越しにコンパイルする。この場合、100Mbpsの回線速度をコンパイル作業の
負荷が上回らなければいいわけですよね？

ご教示ください。

**名無しさん＠お腹いっぱい。** · 2008/08/07(木) 10:34:25

NFSマシン上でバイナリパッケージを作成し、それをインストールする

**名無しさん＠お腹いっぱい。** · 2008/08/07(木) 13:15:12

sh5以降、ひょっとして新しいCPUって無いんじゃね?

**名無しさん＠お腹いっぱい。** · 2008/08/07(木) 19:31:20

UDF って便利?

**名無しさん＠お腹いっぱい。** · 2008/08/07(木) 22:03:14

そこでItanium2ですよ

**名無しさん＠お腹いっぱい。** · 2008/08/07(木) 23:06:38

自治体、金融機関、教育機関へ納入するデスクトップPCをLinuxで
だってお、NetBSD+MIPSで勝負する漢な企業はおらんのかお

IBMとLinuxがMSフリーのデスクトップPC提供へ
ttp://www.atmarkit.co.jp/news/200808/07/ibm.html

**名無しさん＠お腹いっぱい。** · 2008/08/07(木) 23:18:55

>>677
新しく作られたCPUはないかもしれないが、移植されてないCPUは山ほどあるな。
そもそもMIPS64なんて動いているとはとうてい言えない状態だし、
ARMだって最新のはどんなもんだか。

**名無しさん＠お腹いっぱい。** · 2008/08/07(木) 23:29:47

M32Rなんかおもしろいだろうな。

**名無しさん＠お腹いっぱい。** · 2008/08/07(木) 23:34:31

M32Rは実際問題として入手可能なターゲットがないからな。
MMUつきで現実的に入手できるのはCQ出版が出してる10万のFPGAボードくらいか。
toolchainはそこそこ動くだろうがpthreadとatomic opだけでも挫折しそうだ。

**名無しさん＠お腹いっぱい。** · 2008/08/08(金) 00:10:49

Mac G5も中途半端なコード突っ込んだ状態で放置だな。
ia64と同じ人だけど、そういう性格なんか?

**名無しさん＠お腹いっぱい。** · 2008/08/08(金) 03:37:20

>>677,>>681
GPGPU

CUDAなんてモロgccだし…toolchainぐらいは何とか…

**名無しさん＠お腹いっぱい。** · 2008/08/08(金) 08:17:39

くだらないネタでageてないでOSの教科書の触りくらい読んでから出直してこい

**初心者** · 2008/08/08(金) 16:06:49

みんなOSの内容に詳しすぎる
公式スレッドがこれじゃ誰も初心者が寄って来ないと思うが

**名無しさん＠お腹いっぱい。** · 2008/08/08(金) 16:08:56

触り・佐和利
もっとも重要な部分

**名無しさん＠お腹いっぱい。** · 2008/08/08(金) 16:09:33

初心者が寄って来なくて、何か問題ある?

**名無しさん＠お腹いっぱい。** · 2008/08/08(金) 16:14:17

currentを追っかけるのがデフォの時点で初心者なんて寄り付かないと思うの

**名無しさん＠お腹いっぱい。** · 2008/08/08(金) 16:18:38

>>688
当ってんじゃね？

**名無しさん＠お腹いっぱい。** · 2008/08/08(金) 16:20:09

さわりを理解するのは結構大変だね

**名無しさん＠お腹いっぱい。** · 2008/08/08(金) 16:42:23

初心者はタネンバウム本でも丹念に読むべき

**名無しさん＠お腹いっぱい。** · 2008/08/08(金) 18:51:01

初心者が移植性だのなんだの知った被りするから叩かれるだけで、
初心者なりにまずはどう考えて何をどうしたいのかをちゃんと説明できれば
それなりの意図は汲んだ回答は出るんじゃない。

そんなことができるのは初心者じゃないという話もあるけど、
さすがにそこまで指導迎合できるだけの余力はNetBSDにはないな。

**名無しさん＠お腹いっぱい。** · 2008/08/08(金) 19:12:06

「自分だけ初心者じゃありません」と延々同じ内容の投稿が続いておりますが、飽きませんか?

**名無しさん＠お腹いっぱい。** · 2008/08/08(金) 19:22:54

NetBSD全体を見ても技術的に面白いネタって昔と比べたらだいぶ減ったよね
ってのは事実だしねえ。

WAPBLはUFS1でもffsv2 formatのsuperblockがいるわけだけど、
今のnewfs(8)では-O1でUFS1指定してもffsv2 format superblockになるよね。
いつより前のnewfs(8)で作ったffsだとfsck_ffs -c4 しないといけないの?

cvs log newfs | grep fslevel
ですかそうですか

**名無しさん＠お腹いっぱい。** · 2008/08/08(金) 21:57:40

1:1 スレッドは今までで見てもかなり面白いネタなわけだが、
難しすぎてついて行けないという...ww
ま、SunOS が 5 になった時点でわかってたことではあるが。

やっぱ Plan9 や Amoeba の SMP に対する「割り切り」は正しかったという
ことだろうなぁ。「ほとんど誰も参加できなくなる」ことでそれが証明されるというw
やっぱトンプソンやタネンバウムはえらいわw

**名無しさん＠お腹いっぱい。** · 2008/08/08(金) 22:23:16

今後何度もめぐって来そうなスレッドモデルネタ

**名無しさん＠お腹いっぱい。** · 2008/08/08(金) 22:43:43

実際にマルチコアのSMP環境が普通になったところで
複数プロセッサの恩恵を受けてる動かし方は make -jN ばっかりで、
pthreadとカーネル実装でパフォーマンスがどうこう言えるものを動かしてる
ユーザーなんてほとんどいないし、だからベンチマーク結果も出てこない。
そんな状態で1:1だのSAだの中身について騒いだって噛みあわない罠。

とどのつまり
「小難しい理屈ばかりでまともに動かないものより簡単だけどそこそこ動くもの」
ってことのほうが重要だった、ってことだろね。

**名無しさん＠お腹いっぱい。** · 2008/08/08(金) 23:24:57

単に「動かないものより動くもの」だろ。

**名無しさん＠お腹いっぱい。** · 2008/08/09(土) 00:42:18

作りの美しさとかあるべき論とか机上の空論とかいり乱れるから
動かないものをわざわざ主張する人がいるのよ。
it doesn't work unless it's right とかなんとか言って。

bus_space(9)のときのcgdやbus_dma(9)のときのthorpejのように
自分で作業する気のある人が主張するならともかく、
自分で動くようにする気も使う気もないのに文句言う香具師おおすぎ。

やっぱヒモ付きでやってる人がいないと前に進まないのかも。

**名無しさん＠お腹いっぱい。** · 2008/08/09(土) 14:35:36

> it doesn't work unless it's right
なんてニュアンス?

**名無しさん＠お腹いっぱい。** · 2008/08/09(土) 15:06:41

正解なくば実装無し、かな?

**名無しさん＠お腹いっぱい。** · 2008/08/09(土) 15:18:39

正解なくば実装無し、かな?

**名無しさん＠お腹いっぱい。** · 2008/08/09(土) 16:14:01

正しくなければ動かない、ってそのまんま訳すと
逆にいつまでも動かない実装に対する揶揄(それ正しくないんじゃネーノ)に
なってしまうな。

**名無しさん＠お腹いっぱい。** · 2008/08/09(土) 17:45:16

>>701
>自分で動くようにする気も使う気もないのに文句言う香具師おおすぎ。

ん、このスレのこと?

**名無しさん＠お腹いっぱい。** · 2008/08/09(土) 19:43:59

正しくなければ動いてるとはいわない、じゃないか?

**名無しさん＠お腹いっぱい。** · 2008/08/09(土) 19:48:04

bus_space, bus_dmaに関しては
「共通のMIドライバを記述可能なAPI」
っていう「正しい解」が定義されてたわけよ。
だから、動いてるコードがなくても設計段階で正しいかダメか主張できた。

一方、 1:1 と N:M の場合は究極の目標はパフォーマンスだけだから、
どっちが正しいなんて正解はなくて、ある程度動くものができたところで
ベンチーマークして優れている方を選択、となるべき話。
過去の bus関連のAPIとは次元が違う。

なのに、なんとなく N:M のほうが説得力ある、数字が大きいから、
論文ネタとして真面目に理論実証したから、という本質でない理由で
暗黙的に「SAがあるべき究極の姿だ」って思い違いが生じてる気がする。
bus_dmaのbounce buffer神話の弊害だな。

**名無しさん＠お腹いっぱい。** · 2008/08/09(土) 19:52:05

it doesn't work unless it's right
はLinuxや他の*BSDでよく出てくる
it's right because it works
の対義語として出てきただけ。
公式ページのGoalsのページのどっかにあるよ。

**名無しさん＠お腹いっぱい。** · 2008/08/09(土) 20:04:05

>>706
こんなガラパゴス以下のスレ相手にされてるわけねーじゃん。
本家のMLのことだろ。

**名無しさん＠お腹いっぱい。** · 2008/08/09(土) 20:48:30

ガラパゴスってそんな悪いもんじゃないぜ

**名無しさん＠お腹いっぱい。** · 2008/08/09(土) 22:32:33

中の人はそう思ってるからますます救いようがないんだよな...

**名無しさん＠お腹いっぱい。** · 2008/08/09(土) 23:41:33

reasonable、だよ。昔からの基準は。知らんの?

**名無しさん＠お腹いっぱい。** · 2008/08/09(土) 23:48:55

>>713みたいに感覚だけで文句を言う人がいるわけですね

**名無しさん＠お腹いっぱい。** · 2008/08/10(日) 03:17:02

pthreadが当初想定していたのは数千数万のスレッドが動く世界で、
それならM:Nが必須なのだが、
Javaの実装に役立たなかった時点でSolarisのM:Nは死んだ。
今となってはスレッドを確実にコントロールできる1:1がreasonableな解に見える。
NetBSDの人たちはSolarisで成し得なかったことをやれる見通しがあるのだろうか。
それはかなり凄い事だと思うが。

**名無しさん＠お腹いっぱい。** · 2008/08/10(日) 04:10:29

「M:Nが必須」と言っていたような記憶がなんとなくあるから
「今動いてなくてもいつかやらなければいけない」と思ってるだけ
の人が主張はするけど頭も手も動かさないので進まない状態
なわけですよ

**名無しさん＠お腹いっぱい。** · 2008/08/10(日) 06:02:44

これは大掛かりな仕様変更だから、期間定めて短期集中的にやっちゃったほうが
いいと思うんだけどねえ、他のは後回しにしても
音頭取ってくる誰かをみんなして待ってる状態

**名無しさん＠お腹いっぱい。** · 2008/08/10(日) 06:27:55

SAの削除と1:1への変更はとっくの昔に済んでるんだから、
今騒いでるのはrevivesaを5.0に入れるかどうかじゃないの?

費用対効果で見ればわざわざ無理に入れる必要ないと思うけど。

**名無しさん＠お腹いっぱい。** · 2008/08/10(日) 12:09:03

revivesaって、SAあきらめてないわけじゃなくて
要するにCOMPAT_40のためだけなの？そのこだわりはある意味すげえな。

**名無しさん＠お腹いっぱい。** · 2008/08/10(日) 15:24:40

理想性能のために入れろと言う人と
COMPAT_40のために入れろと言う人と
そんなの関係なく趣味で書いてる人と
SMPコードメンテにSAは邪魔と思ってるadと
四派で噛み合わない議論を展開中

そのへんcoreがきっちり仕切るFreeBSDや
Theoの一声で決まるOpenBSDと比べて
責任者不在でグダグダのNetBSDです

**名無しさん＠お腹いっぱい。** · 2008/08/11(月) 09:54:27

今いちばんその可能性があるのは ad なんじゃないのかな?
つーか、いま ad が精神的に消耗してどっかいっちゃうとめちゃ困るのは
見えてると思うんだけど..
ヘタするとプロジェクトの存亡にかかわらないか?
ad どっかいっちゃうと 1:1 てメンテできるのか?
それとも revivesa ベースにして m:n 復活できるとでも思ってるのだろうか...

**名無しさん＠お腹いっぱい。** · 2008/08/11(月) 09:57:19

>>720
1. 理想性能のために入れろと言う人と
2. COMPAT_40のために入れろと言う人と
3. そんなの関係なく趣味で書いてる人と
4. SMPコードメンテにSAは邪魔と思ってるadと

匿名で意思表明してもしょうがないかも知れんが...

4 に賛成。ad が危惧してるんだからとりあえず 2 はやめよう。
別枝でいいやん。バウンスバッファの時みたいに、un-official バイナリでも
作ればいい。

**名無しさん＠お腹いっぱい。** · 2008/08/11(月) 10:49:30

adは金で雇われてるんだからすぐにいなくなることはないと思うよ。
いつまでの契約なのか知らんけど。

逆に言うと口だけのやつはすっ込んでろ、つーことになるのかもしれんが。

**名無しさん＠お腹いっぱい。** · 2008/08/11(月) 11:26:30

adは幼女とちゅっちゅしたいと言って去ったと聞きましたが。

**名無しさん＠お腹いっぱい。** · 2008/08/11(月) 11:30:21

どこで誰に?

**名無しさん＠お腹いっぱい。** · 2008/08/11(月) 11:37:37

>>723
えっ? あれって、2ヵ月くらいでとっくの昔に終ったんじゃないの?
まだ続いてんの? そんなに寄付あったのか??

**名無しさん＠お腹いっぱい。** · 2008/08/11(月) 16:01:05

匿名以前に、日本語で意思表明するのが意味がないな。

So, Omowanaika?

**名無しさん＠お腹いっぱい。** · 2008/08/11(月) 16:59:43

yon ni, i-ppyou.

**名無しさん＠お腹いっぱい。** · 2008/08/11(月) 19:04:54

曽田さんは>>715の言う「数千数万のスレッド」をSA擁護の例に挙げてなかったっけ。
1+2番、と言っているように感じたが、氏がここを見てたら何かしら伝わるんじゃない。

**名無しさん＠お腹いっぱい。** · 2008/08/11(月) 20:31:47

スレッドが大量に作れれば、シミュレーションには便利かもね。
でもthreadを使わなくても書けると思う。
一方でパフォーマンスが重要なアプリケーションは、
1:1スレッドを前提に書かれている。
アプリケーションプログラマが頑張ることになっちゃったけど、
M:Nでは1:1よりパフォーマンスが出ないんだから、しょうがない。

**名無しさん＠お腹いっぱい。** · 2008/08/11(月) 20:37:30

逆に言えば、1:1を上回るパフォーマンスさえ出ればM:Nの実装コストは正当化される。
「SAが実装された暁には!」という夢を見るのも、また一興か。

**名無しさん＠お腹いっぱい。** · 2008/08/11(月) 21:15:06

で、その日まで枝でいいじゃん。そういう意味じゃ revivesa は名前が悪いね。
longandwindingsa とかw

**名無しさん＠お腹いっぱい。** · 2008/08/11(月) 22:47:58

eventualsaとか
forthcommingsaとか
undeadsaとか

つーか、それよりfixsaはどーなっとるんよ

**名無しさん＠お腹いっぱい。** · 2008/08/11(月) 22:57:57

diehardsa
zombeesa
foreversa

**名無しさん＠お腹いっぱい。** · 2008/08/11(月) 22:58:36

sainyourheart

**名無しさん＠お腹いっぱい。** · 2008/08/11(月) 22:59:49

saー、saー、お星になったのねぇ～w

**名無しさん＠お腹いっぱい。** · 2008/08/11(月) 23:03:21

youareshocksa

**名無しさん＠お腹いっぱい。** · 2008/08/12(火) 01:49:23

Mercurial or GITみたいな分散型SCMに移行すれば俺ブランチも作りやすくなるけど、
ブランチ切る抵抗を減らしてしまうのは、果たしてプロジェクト全体にとって
幸せなことなのかどうか、ちょっとわからんな。BSDだとGPL縛りもないし。

**名無しさん＠お腹いっぱい。** · 2008/08/12(火) 02:25:00

ブランチの作りやすさはあんまり重要じゃなくて
マージまでたどり着けるかどうかのほうが。
doc/BRANCHESには屍累々だし。

顧客でも締切でもLinusやTheoみたいな独裁者でも
なにかしら駆動するもんがないと厳しいんじゃない。

**名無しさん＠お腹いっぱい。** · 2008/08/12(火) 11:21:08

なんかまた違う話が出てるぞ...ww 少なくとも sa に関しては「ブランチ切る」のは
終ってるぞ? 統合するのか並行で行くのかが争点なんだけど。

**名無しさん＠お腹いっぱい。** · 2008/08/12(火) 11:23:41

ひょっとして、「ブランチ≒いずれは統合」とか、思ってんのかな?
枝のまま消えるのは、それでいいじゃん。リポジトリには残って参照できるんだし、
とりあえずの実装が正しいか試せるのが枝なんだから、別の方法を見出せたならば
それで十分役に立ってる。

**名無しさん＠お腹いっぱい。** · 2008/08/12(火) 11:48:12

リリースブランチ以外で「trunkとは別の方向に進む」っていうブランチを作る文化は
NetBSDにはあまり認知されてないように見えるけど。
つーか、独立してまでメンテするマンパワーないし、
trunkの新機能から取り残された感が出てくると萎えるし、
実際問題としてブランチ切ってもよほど興味を引かない限り
誰もチェックアウトすらしないし。
fixsaもrevivesaも誰も結果レポートしないから止まってる面もある。

世間一般のプロダクトだとまた話は別なんだろうけど。

**名無しさん＠お腹いっぱい。** · 2008/08/12(火) 11:48:48

yasa
zsa

**名無しさん＠お腹いっぱい。** · 2008/08/12(火) 17:53:38

誰も興味ないし誰も結果レポートしないんだから
マージする必要もないんじゃ

**名無しさん＠お腹いっぱい。** · 2008/08/12(火) 20:06:52

問題は技術的な理想論を実務上の理由で否定する結論を誰も下せないこと。
あるべき論と文句だけは皆いっちょ前だし、そんな矢面に立っても得すること何もないし。
OpenBSDならtheoの一声なんだろうけど。

**名無しさん＠お腹いっぱい。** · 2008/08/12(火) 20:48:44

あんたもしつこいな。だから、実際手動かしてる ad とかが判断下すように
持ってけばいいんだよ。thorpej がノシて来た時もそうだったし。
元からそんな人数居たわけじゃないし。

**名無しさん＠お腹いっぱい。** · 2008/08/12(火) 21:05:35

やっぱ、

1. 少人数で維持が可能で大勢に理解できる規模にプロジェクトを抑える
2. SMP はプロセスのメインスレッドの処理 CPU を固定する等、単純な構造にする

ために、マイクロカーネルに移行すべきだな。コンテキストスイッチの
オーバーヘッドが大きいんなら特権空間に置けばいいと思うし。

**名無しさん＠お腹いっぱい。** · 2008/08/12(火) 21:06:11

でもって、それは Amoeba であり、Plan 9 なのでした。ちゃんちゃんw

**名無しさん＠お腹いっぱい。** · 2008/08/12(火) 22:29:22

そして>>727にもどる

**名無しさん＠お腹いっぱい。** · 2008/08/12(火) 22:37:37

>>746
coreであるagc自身が

we're currently in feature freeze for NetBSD 5.0, and we're
nearing the end of that period. There are some things that we still
have to finish off, such as (in no particular order):

+ wrstuden-revivesa merged and 4.0 SA threaded apps working outta da
box on 5.0

なんて書いてるわけだが、まあ頑張って説得でもなんでもしてみてくれ。

thorpejがやってきたのは実務論優先の切り捨てじゃなくて自論の体現だよ。
もうそんなパワーのあるメンバーいないのに理想だけは変えられない性。

**名無しさん＠お腹いっぱい。** · 2008/08/12(火) 23:41:00

まあそんな悲観論あと百回並べてみたとこでそれも同じことだろ?

**名無しさん＠お腹いっぱい。** · 2008/08/13(水) 00:51:32

持ってけばいいんだよ、なんて草場の陰で待望論してないで
現実知って行動しろよ、ってだけだけどな。

**名無しさん＠お腹いっぱい。** · 2008/08/13(水) 03:50:16

現実の話なら、-currentを安定動作するところまで持っていけるかどうかの
方がずっと心配だよ。負荷かけるとなんかturnstileあたりで詰まっちゃうし。
adはお休みモードになっちゃったみたいだし、誰かちゃんと直せるのかなあ。

revisesaは、diffみる限り局所的な変更で済みそうだから、ずっと問題は
小さからろ。

**名無しさん＠お腹いっぱい。** · 2008/08/13(水) 04:27:04

turnstileはさっきthorpejがassertつっこんでたから認識はされてるんじゃない。
同じ原因と推測される不具合が一月誰も手を付けずに放置だったら心配だが、
1,2週間おかしいくらいでガタガタ言うんじゃねーよ。

そもそも、おかしいのがわかってるんだったらこんなとこでグダグダ言ってないで
send-prしろよ。再現させる方法がわかってるかどうかでもかなり変わるし、
見てるだけ待ってるだけで良くなると思ってる方がどうかしてる。

**名無しさん＠お腹いっぱい。** · 2008/08/13(水) 06:45:34

わっふるわっふる

**名無しさん＠お腹いっぱい。** · 2008/08/13(水) 14:51:46

>>754
> 見てるだけ待ってるだけで良くなると思ってる方がどうかしてる。
自分以外は必ず「見てるだけ待ってるだけ」だと思い込む方がよっぽどどうかしてるんだが。

**名無しさん＠お腹いっぱい。** · 2008/08/13(水) 18:44:09

>>誰かちゃんと直せるのかなあ。
これって見てるだけ待ってるだけとしか思えんのだけど。違ったのならスマンな。

**名無しさん＠お腹いっぱい。** · 2008/08/14(木) 17:45:07

>757
そんなこと言ったってね、私は寝てないんだ。

**名無しさん＠お腹いっぱい。** · 2008/08/14(木) 17:54:46

>>758
こっちだって寝てないですよ！

**名無しさん＠お腹いっぱい。** · 2008/08/14(木) 18:44:14

2ch見てウダウダ書き込みする暇はあってもsend-prする時間はないってか。
英語のベンキョは大事だネ

**名無しさん＠お腹いっぱい。** · 2008/08/14(木) 21:24:10

>>760
英語でおk

**名無しさん＠お腹いっぱい。** · 2008/08/15(金) 02:01:46

ぐぐってみた。
http://jibun.atmarkit.co.jp/lcareer01/rensai/topi04/topi01.html
http://www.geekpage.jp/blog/?id=2008/2/13
http://kmuto.jp/debian/article/osm200601.html
http://www.itmedia.co.jp/enterprise/articles/0412/01/news009.html

**名無しさん＠お腹いっぱい。** · 2008/08/15(金) 09:12:53

NetBSD 4.0/i386を使っています。
gdbでwatchをセットすると実行が激しく遅い感じなのですが、自分だけでしょうか?

処理が増えて遅くなるんでしょうが、実際のところ、ものすごくシンプルなコードでやっても
激遅で、正直実用に堪えない感じです。ちなみにCPUはCore 2 Duo 2.2GHzです。

似たようなスペックのハードに入ったLinux(Ubuntu)上で全く同じことをしてみたら全然速いので、
NetBSDの方には何か問題があるようにも思えます。
自分が何かヘマをしているのかもしれませんが、どなたか心当たりはありませんでしょうか。

**名無しさん＠お腹いっぱい。** · 2008/08/15(金) 20:46:10

watchは、そもそも、遅いものだと思うがいかがなものかな。
Linuxがなにかずるをしていないか?

**763** · 2008/08/15(金) 21:48:36

>>764
ずるっていうか、デバッグレジスタ使ってるかな～、みたいな。
ptrace()かな～、みたいな。
NetBSDの人はwatchなんてものは使わないのかな～、みたいな。
あ、全然面白くないですね。すみません。

**名無しさん＠お腹いっぱい。** · 2008/08/15(金) 21:50:00

NetBSDでサポートされているかは知らないが、
gdbならhardware watchpointに対応していれば問題ない速さで動くはず。

**名無しさん＠お腹いっぱい。** · 2008/08/15(金) 22:47:56

gdb6/gdb/config の下いじったら使えるようになったりしない?
いちおうまだ古いCPUもサポートしてるはずなので、デフォルトで使わないようになってるのかもしれない。
libmみたいに動的に切り替えるのがいいんだけどね。

**名無しさん＠お腹いっぱい。** · 2008/08/15(金) 23:14:10

>>765
>NetBSDの人はwatchなんてものは使わないのかな～、みたいな。
実際、少なくともここにいる人はほとんど使ってないんじゃない。
NetBSD使う理由の9割くらいはカーネルだし、ユーザーランド環境はいまいちだし。

**名無しさん＠お腹いっぱい。** · 2008/08/15(金) 23:15:50

カーネルって、カーネルでなにしてんの？w