トップページunix
1001コメント317KB

NetBSD その11

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん@お腹いっぱい。UNIX時間(+0900)35年,2005/04/03(日) 23:49:15
``もちろんNetBSDです。''
http://www.netbsd.org/

お約束、関連リンクは>>2-10あたりにあるかもしれない。

前スレ
NetBSD その10
http://pc8.2ch.net/test/read.cgi/unix/1106336671/
0449名無しさん@お腹いっぱい。2005/05/27(金) 04:30:56
>>448
MD も sh3 の下はかなりフィードバックしてるような希ガス
0450名無しさん@お腹いっぱい。2005/05/27(金) 08:47:42
netbsd-sh3-jpのMLが元気だった頃の話?
あれもSEIL関係だったということなら
へぇそうだったのか、とは思うけど最近は
さっぱりね。SHに見切りつけちゃったからか。
0451名無しさん@お腹いっぱい。2005/05/27(金) 10:22:19
>>441
最近mipsでは遊んでないんですが、hpcmipsでもcurrentはダメなんですか?
0452名無しさん@お腹いっぱい。2005/05/27(金) 11:15:50
>>450
SEIL関係でしょ。当時の話
ttp://www.netbsd.org/gallery/events/interop-tokyo-2001.html#yamamoto
を見ると
Specs: SH3
NetBSD 1.4 + KAME (next version of the firmware will be 1.5.1),
ってあるし。
0453中の人2005/05/27(金) 12:26:32
暇ねえんだよ。人足りねえんだよ。

やりたいことはたくさんあるが積んだまま。
0454名無しさん@お腹いっぱい。2005/05/27(金) 21:15:29
>>451
ひとまず3.0のカーネルと-currentのカーネルとでbuild.shが完走できるか試してみて。
0455名無しさん@お腹いっぱい。2005/05/27(金) 21:51:52
>>453
まだできてないから commit もされない、ってのなら全然問題ないけど、
中ではできてるけど外に出すには暇がない、って話だとちょっと悲しいかも。

Wasabi Certified NetBSD なんてのを見ると食うためにはしかたないのかなあ、
これも BSD ライセンスのなせる業か、なんて思っちゃう。
0456名無しさん@お腹いっぱい。2005/05/27(金) 22:05:28
まあそういう見返りが欲しいという人は Linux や
Hurd の開発をするのがいいんじゃないの。
見返りは歓迎するが強制はしないというのが BSD
ライセンスの本質なんだし。
0457名無しさん@お腹いっぱい。2005/05/27(金) 22:12:43
なんにもしてないから見返りなんて求めないけど、ただ残念ってだけ。
昔はNetBSDは商業主義とは一番無縁なところにいたから純粋に技術論ができてたような気がするんだけど、
そうではなくなってしまったNetBSDの先行きはどうなるのかなあ、とか。
0458名無しさん@お腹いっぱい。2005/05/27(金) 22:19:43
BSDLは昔からあったが?
0459名無しさん@お腹いっぱい。2005/05/27(金) 22:26:44
そうだね。
0460名無しさん@お腹いっぱい。2005/05/28(土) 01:20:26
コードも書けない奴はSolarisでも使ってろよ
0461名無しさん@お腹いっぱい。2005/05/28(土) 01:22:05
失礼だな
0462名無しさん@お腹いっぱい。2005/05/29(日) 00:32:14
NetBSDすれなんだから、(M)マッタリ(I)いこうよ
0463名無しさん@お腹いっぱい。2005/05/29(日) 00:42:33
まったりできない(MD)です。
0464名無しさん@お腹いっぱい。2005/05/29(日) 22:04:09
>>462-463 ワラタヨ
0465名無しさん@お腹いっぱい。2005/05/30(月) 01:30:19
二律パイパン(←なぜが変換できない)がNetBSDの醍醐味
0466名無しさん@お腹いっぱい。2005/05/31(火) 02:21:01
>>443
WindRiverが使おうとしていたのはBSD/OSです。
SMPとfine-grained lockingが欲しかったという話ですが、
そのためにBSDIのOS事業を買収して引導を渡し
BSDIに雇用されていた12人のFreeBSDの開発者をハロワ通いにさせた挙句
買収の目的まで頓挫とはどうしちゃったんでしょうね。
0467名無しさん@お腹いっぱい。2005/05/31(火) 21:34:52
微妙にスレ違い
0468名無しさん@お腹いっぱい。2005/06/01(水) 01:57:49
ねえ、auichドライバってなんて読むの?
ドイツ語風にオウイッヒ?アウイッヒ?アウチ?
0469名無しさん@お腹いっぱい。2005/06/01(水) 03:38:59
Audio I/O Controller Hub
0470名無しさん@お腹いっぱい。2005/06/01(水) 13:50:26
そもそも「auich」を声に出して読む機会なんてないような気がするん
だけど、英語的に読むなら「おーいく」かなあ。

auacer: おーえいさー
autri: おーとらい
auvia: おーびあ/おーばいあ
auixp: おーあいえっくすぴー
0471名無しさん@お腹いっぱい。2005/06/01(水) 23:47:38
3.0_BETA
0472名無しさん@お腹いっぱい。2005/06/02(木) 00:02:02
ttp://mail-index.netbsd.org/source-changes/2005/03/17/0012.html
すでにイプシロン、って感じ?
0473名無しさん@お腹いっぱい。2005/06/02(木) 02:10:00
altqは3.0にも入りそうにないですか?
入ったらインストールしてみようかと思ってる人間なんですが。
0474名無しさん@お腹いっぱい。2005/06/02(木) 04:22:14
3.0BETAには一応取り込まれているようだな<altq
0475名無しさん@お腹いっぱい。2005/06/02(木) 21:38:29
src/sys/altq/以下のファイルと>>12のpf altqが違うものなのかわかってないオレ。
0476名無しさん@お腹いっぱい。2005/06/03(金) 03:46:48
altqの性能とかってどうなの?どっかにグラフとか落ちてないですか
0477名無しさん@お腹いっぱい。2005/06/03(金) 09:19:31
http://www.csl.sony.co.jp/person/kjc/software.html
このへん?
0478名無しさん@お腹いっぱい。2005/06/04(土) 01:49:40
-Wuninitializedはともかくとして、-Wcast-qualや-Wshadowで発覚したバグってあるんすかね。
0479名無しさん@お腹いっぱい。2005/06/04(土) 11:09:23
それでバグにするような奴はそういうオプションを使うことなどないような気がする。
0480名無しさん@お腹いっぱい。2005/06/04(土) 12:50:48
>>479 source-changes読んでない人ですか?
0481名無しさん@お腹いっぱい。2005/06/04(土) 16:41:36
>>478swapctl(2)
0482名無しさん@お腹いっぱい。2005/06/04(土) 18:37:41
>>481
う〜ん。constな領域を指すポインタをconstでないメモリを指すポインタを
想定している関数に渡してそのポインタ経由で書き込みするのは問題だろう
けど、constな領域でないポインタを渡していて呼ばれる側の関数のプロト
タイプがconstになっていても実使用上はバグとして発現はしないような。
0483名無しさん@お腹いっぱい。2005/06/04(土) 21:27:00
>>478
memcpy の src と dst が反対になってたってバグ (!) が
netsmb/iconv.c と netsmb/smb_crypt.c で直ったようだよ。
0484名無しさん@お腹いっぱい。2005/06/04(土) 21:28:45
失礼、smb_crypt.c は間違いだった。もう一箇所あったような
気がしてたんだけど。
0485名無しさん@お腹いっぱい。2005/06/05(日) 01:05:06
-Wcast-qual 指定して __UNCONST() 使いまくってたら意味ないじゃん...
0486名無しさん@お腹いっぱい。2005/06/05(日) 01:14:33
>>482
何が言いたいのかわからん。
実使用上、って何? crashしなければokてこと?

>>485
__UNCONST使うとき十分注意しなければそのとおり。
まあ__UNCONST使ってる場所はgrepとかで機械的に見付けられるので
意味無いというわけでもないかと。
0487名無しさん@お腹いっぱい。2005/06/05(日) 01:21:58
どう見てもbuild通すためだけに使ってる人がいますな。
0488名無しさん@お腹いっぱい。2005/06/05(日) 01:25:38
>>486
crashしなければっつーか、実際にROのメモリに書き込みにいくようなコードが
-Wcast-qualで発見された例があるのか、ってことが訊きたかったのよ。
わかりにくくてすまん。
0489名無しさん@お腹いっぱい。2005/06/05(日) 01:33:30
(void *) で渡す時はどうせサイズもわかんないんだから const も volatile も
警告なんか出さずに渡された側の責任で決めればいいじゃんという気もするけど、
どうなんだろ。
0490名無しさん@お腹いっぱい。2005/06/05(日) 01:36:24
>>489
ハァ?
データのサイズとconst/volatileという属性にはなんの関係のないだろうが
0491名無しさん@お腹いっぱい。2005/06/05(日) 01:46:37
void *使うのはopaque型で渡したいからで関数APIでは引数の具体的な型は関知しないってこともあるんじゃないの?
0492名無しさん@お腹いっぱい。2005/06/05(日) 13:28:00
>>420
VIM_EXTRA_OPTS= --enable-ximでmake installしてないと、ximで入力できないよ。

inputmethod/kinput2でも、inputmethod/uimでも、入力はできますよ。

0493名無しさん@お腹いっぱい。2005/06/05(日) 17:46:43
>>488
コンパイラが
「この関数の引数はconst pointerだから値を変更することは無いハズ」
って思って呼び出し側のコードをoptimizeしたら
ROじゃなくてもおかしくなるかもね。
gccがそういうoptimizeをするかは知らんけど。
0494名無しさん@お腹いっぱい。2005/06/05(日) 17:50:42
>>491
そういうことはわりとあるねえ。
でもCではそんな意図は記述できないし。。。
0495名無しさん@お腹いっぱい。2005/06/05(日) 18:06:42
>>493
ないはず、と思ってたのに変更されてたらその旨警告が出るわけだから、
意図せず変更されていたらそういう最適化はしないような気がする。
0496名無しさん@お腹いっぱい。2005/06/05(日) 18:19:32
>>495
意味わかりません。
その旨警告が出る、ってのは何の話?
意図せず変更されたかどうかなんてコンパイラにはわからんでしょう。
0497名無しさん@お腹いっぱい。2005/06/05(日) 20:02:06
スマン、呼び出し側って呼び出し元のほうね。呼ばれた側と勘違いしてた。
プロトタイプ宣言で暗黙的にキャストされた先の型までコンパイラは見てるんすかね。
-fstrict-aliasingの話からすると見てるかもしれないけど修飾型までは見てない?
0498名無しさん@お腹いっぱい。2005/06/05(日) 22:27:07
NetBSDの話から離れて、旅立っていった彼は。
0499名無しさん@お腹いっぱい。2005/06/06(月) 00:13:56
話についていけなくて、おいてけぼりを食った>>498は。
0500名無しさん@お腹いっぱい。2005/06/06(月) 00:29:15
>>498
彼はまた戻って来た。
0501名無しさん@お腹いっぱい。2005/06/07(火) 15:11:34
Summer of Codeのネタ == ここのマダーリスト
という認識でいいですか。
0502名無しさん@お腹いっぱい。2005/06/07(火) 18:49:43
今まで我慢してきたけどもう我慢できん
sendmailの起動が遅すぎ
2.0で、LAPTOPのGENカーネルでsendmailの起動に1分以上かかる
なめとんのかと
これどうにかしてくれよ
1.6.1はこんなに遅くなかったのにな…
まじで、
どうにかしてくれょ
0503名無しさん@お腹いっぱい。2005/06/07(火) 19:07:20
名前引こうとしてタイムアウトしてんでしょ。
そんなの今まで我慢してた君はカコイイ
05045022005/06/07(火) 19:10:18
え…
とくにエラーはでないけどな
CPUはSpeedStepの700MHz
おまいはどんくらいの速度でsendmailの起動にどんくらい?
0505名無しさん@お腹いっぱい。2005/06/07(火) 19:13:20
だから、CPUの問題じゃなくて、DNSのタイムアウト待ちでもしてるんでしょ。
05065022005/06/07(火) 19:20:56
うっそ、なにがなんだかわかんないや
エラーは表示されてないと思うし

同夜ったら調べられるのか教えてくれたらうれしい…
05075022005/06/07(火) 19:37:56
ごめん
ほんとにごめん
起動スクリプト読み直したら
sendmailのエラーが/dev/nullにリダイレクトされてた・・・
エラーが出てたからうざくて殺したのかな・・・
まったく覚えてないや・・・
その場しのぎでやるもんじゃないね

それで、起動が遅かった理由は
/etc/hosts に
127.0.0.1localhosta
って、ごみが付いてた
こんなごみのために数ヵ月悩まされてたのか・・・

答えてくれたひと申し訳ない
そして、NetBSDさん/NetBSDの開発者様・・・
本当にごめんなさい


でも、起動に10秒強かかる
700MHzじゃ こんなもんか?
0508名無しさん@お腹いっぱい。2005/06/07(火) 19:40:01
くだ質
0509名無しさん@お腹いっぱい。2005/06/07(火) 19:40:17
下手な釣りはよせ
0510名無しさん@お腹いっぱい。2005/06/07(火) 19:52:42
俺もそんな経験あるな
カーネル作りなおしてて、そこら中書き換えまくってて
そのままコンパイルしながら寝て朝起きたらどこを書き換えたか忘れてた
全てのファイルをチェックするので一日つぶれた
それから書き換えたときは、どう書き換えたかをかくようにしてる
0511名無しさん@お腹いっぱい。2005/06/07(火) 19:54:18
だから/etcをcvs管理しろと俺様が何度も何度も(以下略
0512名無しさん@お腹いっぱい。2005/06/07(火) 19:55:49
/etcをcvsで管理するってどういうこと?
意味がわからん
0513名無しさん@お腹いっぱい。2005/06/07(火) 19:59:47
コンパイルしながら寝るってどんなスペックのマシンだよ
お前らのマシンでgenericカーネルコンパイルしてその時間教えてくれよ
CPUとメモリと時間
CPU: PentiumIII 800EBMHz
Mem: PC-133 512MB
time: hoge

ってな感じで
0514名無しさん@お腹いっぱい。2005/06/07(火) 20:01:29
話相手が欲しいならよそに行った方が良い。
05155022005/06/07(火) 20:33:08
わたしはこんな感じです

CPU: PentiumIII 700MHz SpeedStep
Mem: PC-100 384MB
time:
real 20m21.462s
user 18m4.989s
sys 1m23.186s

ちょっと、解決した祝いに焼肉行ってきます
0516名無しさん@お腹いっぱい。2005/06/07(火) 21:46:06
>>511
rcsで十分という気も

まあ、何台も書いてるとだいたいなにをどうするとどうなるか覚えちゃってるけど。
0517名無しさん@お腹いっぱい。2005/06/07(火) 22:10:15
NetBSD ユーザってアホばっかりだなプププププ
0518名無しさん@お腹いっぱい。2005/06/07(火) 22:13:51
AppleのIntel採用の話でNetBSD/i386の名前を変えなきゃいけなくなる日が来ますかね。
0519名無しさん@お腹いっぱい。2005/06/07(火) 22:18:31
変える必要ないっしょ。
0520名無しさん@お腹いっぱい。2005/06/07(火) 22:21:18
>>516
普通に動かしていれば/etc/securityが毎晩rcsでバックアップとってくれるけどね。
0521511 ではないが...2005/06/07(火) 22:25:44
>>516
cvs up -r TAG で /etc 全体をお好みの状態にできるのがいいんだよ。
同じ構成のマシンを用意するのも楽チンだしね。リリース毎の違いも把握できる。

>>517
まあそういうことだ。
0522名無しさん@お腹いっぱい。2005/06/07(火) 22:36:08
>>520
デフォルトのdaily設定だと作業が佳境にはいってきた時分にディスクが一斉に動き出して萎えたりしない?
思わずdailyの設定を日曜の朝8時とかにしちゃうオレ。
0523名無しさん@お腹いっぱい。2005/06/07(火) 22:39:28
お前は毎日日曜日か
0524名無しさん@お腹いっぱい。2005/06/07(火) 22:41:53
>>523
毎日日曜日テラワロス
0525名無しさん@お腹いっぱい。2005/06/07(火) 22:51:25
>>518
来年出荷らしいから、EMT64 なのかなぁ.. だったら、macamd64?
0526名無しさん@お腹いっぱい。2005/06/07(火) 22:56:45
>>525
どこぞの日記によるとIA32らしい。
0527名無しさん@お腹いっぱい。2005/06/07(火) 22:58:50
amd64のMACHINE_ARCHはx86_64だからそっちは全然問題ないけどね。
0528名無しさん@お腹いっぱい。2005/06/07(火) 23:19:48
>>522
2 月 29 日にすると 4 年に一度くらいで済むぞ。
0529名無しさん@お腹いっぱい。2005/06/07(火) 23:21:42
>>527
じゃあ、macintel。まっきんてる!
0530名無しさん@お腹いっぱい。2005/06/07(火) 23:33:26
700MHzで20分強でできるんだ
233MHzだけど1時間以上かかるな、メモリも少ないからか
ってか、一人しか書かないんだな
マシン買い替えようと思ったから参考になると思ったんだが
0531名無しさん@お腹いっぱい。2005/06/07(火) 23:48:43
dailyとかもrc.dみたいに機能毎に分けてperiodic.d/かなんかに突っ込むと
嬉しかったりしないかなと思う。
0532名無しさん@お腹いっぱい。2005/06/08(水) 00:07:57
>>529
新しいportの名前をどうするかが問題なのではなくて今のi386をどうするかが問題なんだけど。
0533名無しさん@お腹いっぱい。2005/06/08(水) 00:14:37
3とか2GHz台のやつはおらんのか?
単純に考えて5分とかでコンパイルできるんだな
カーネルだけのためにそんなマシン使うのもな
0534名無しさん@お腹いっぱい。2005/06/08(水) 00:18:50
GENERICカーネルのコンパイル時間って言ったって、アーキごとにぜんぜん違うからまったく意味がねー。
>502はアホだ。
0535名無しさん@お腹いっぱい。2005/06/08(水) 00:19:31
今のi386を、machine=i386, arch=x86 にするのが先でないかい?
0536名無しさん@お腹いっぱい。2005/06/08(水) 00:27:50
今のsys/arch/x86はいわゆるATismなものもつまっているので MACHINE_ARCH=x86 は無理だしょ
pc98のときの議論では MACHINE_ARCH=i386 MACHINE=at386みたいな何か が現実的路線という結論だったか
0537名無しさん@お腹いっぱい。2005/06/08(水) 00:29:45
今更名前いじってもメリットないからi386でいいよ。
0538名無しさん@お腹いっぱい。2005/06/08(水) 00:34:22
PC98 までニラんだ一般化は PC98 気合い入れて面倒見る人が
居ないとムリ。つまり、今も昔もこの先もムリ。
0539名無しさん@お腹いっぱい。2005/06/08(水) 00:36:05
sys/arch/i386以下をMACHINE_ARCH=i386依存なファイルだけにしてMACHINE=i386依存なファイルを分離しないと、
MACHINE!=i386かつMACHINE_ARCH=i386なポートがMACHINE_ARCH=i386依存なファイルだけを参照しようとしても置く場所がないの。
という問題が解決される
0540名無しさん@お腹いっぱい。2005/06/08(水) 00:42:08
sys/arch/sun68k なんつうもんもあるよね。PC/AT、PC98、MacIA32(??) で
ディレクトリきれいにしようとすると MACHINE_ARCH 用 1 個だけでは
済まんのでは?
05415332005/06/08(水) 00:44:00
おもいきりPentium4のことをいってたつもりだけど
i386で

だれか、やってみてちょ
0542名無しさん@お腹いっぱい。2005/06/08(水) 00:46:03
>>538
pc98もsun386もtownsもintelなappleマシンも同じことだから
まだ見ぬintel-appleマシンに対するportの気合いがpc98と同程度なら無理だろね。
0543名無しさん@お腹いっぱい。2005/06/08(水) 00:57:11
>>540
sun68kはsun2とsun3の共用できる部分の置き場所でMACHINE_ARCHじゃないよ。hpcもそう。

MACHINE_ARCH=i386の共通部分
i386とx86_64のCPUとしての共通部分
pcat,amd64のATismとしての共通部分
pcat,pc98,mac86(?) etc.の各MACHINE依存部分
くらいは置き場所作らないといけないかもしれんがMACHINE_ARCHを何にするかとはあまし関係ない。
0544名無しさん@お腹いっぱい。2005/06/08(水) 01:01:08
>>541
amd64は無視ですかそーですかそーですか。
0545名無しさん@お腹いっぱい。2005/06/08(水) 01:03:20
実はMACHINE_ARCH=x86_64はあってもsrc/sys/arch/x86_64/はないのね。
さらにEMT64なappleマシンが出てくるとまた一仕事要りますな。
0546名無しさん@お腹いっぱい。2005/06/08(水) 01:26:42
>>543
あのね、MACHINE_ARCH がもういっこ要るとは書いてないでしょ、>>540 には。
で、pcat(つー名前だとして)と mac86(同)はほとんど違いはないだろうし、
そいつらと pc98 はだいぶ違うから、pcat と mac86 用の共用ディレクトリも
要るんじゃない?
どうするにせよ、mac86 分ける作業する時に pc98 の事情に配慮できる人が
ゴリゴリ選別する、くらいしか進展の可能性はないんじゃない?
0547名無しさん@お腹いっぱい。2005/06/08(水) 01:30:42
>>541
1.6→2.0でgcc2→gcc3になっててそれだけで倍くらい遅くなってるし
GENERICはどんどん太る一方なのでバージョンも決めないと意味なし。
0548名無しさん@お腹いっぱい。2005/06/08(水) 01:31:11
つまりこのままグダグダか。
■ このスレッドは過去ログ倉庫に格納されています