トップページ⇒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/
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.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
つまりこのままグダグダか。
0549名無しさん＠お腹いっぱい。2005/06/08(水) 01:32:28
まだ出てもないのにエスパーだな。
0550名無しさん＠お腹いっぱい。2005/06/08(水) 01:38:00
>>546
MACHINE_ARCHのディレクトリからMACHINE依存のファイルを取り除くことさえできれば、
pcatとmac86の両MACHINEで共用するためのディレクトリなんてあとからでも変えられる
からどうでもいい。
0551名無しさん＠お腹いっぱい。2005/06/08(水) 01:38:13
つまりあれだ、pc98 関係者が macintel のポートやればいいんじゃん。
0552名無しさん＠お腹いっぱい。2005/06/08(水) 01:40:58
>>550
それは要するに、名前だけ決まればすぐにでもできる、ってこと?
0553名無しさん＠お腹いっぱい。2005/06/08(水) 01:45:25
>>552
そうじゃない。今のいわゆるAT互換機用portである MACHINE=i386 を
MACHINE_ARCHと重複しない別の名前に変えられるかどうか、だ。
その名前を何にするかは問題じゃない。
0554名無しさん＠お腹いっぱい。2005/06/08(水) 01:49:30
>>553
うーん、わからんな... >>539 の人とは別人? >>539 で「変えるしかない」って
言ってるわけじゃないのか??
変えずに済む方法も検討中?
0555名無しさん＠お腹いっぱい。2005/06/08(水) 01:54:34
MACHINEがらみもMACHINE_ARCHがらみも全部sys/archにぶち込んでるのが悪い。
sys/dev/cpuか何か作れ。

とか言うのは厨。
0556名無しさん＠お腹いっぱい。2005/06/08(水) 01:58:13
>>554
pcat以外のMACHINE_ARCH=i386ポートを素直に入れるには変えるしかないんだけど、
単に変える作業がめんどくさいとか、uname(3)がMACHINEを返すからそこでi386が
返ってくることを期待しているサードパーティーのソースのないプログラムが
困るかもしんないとか、そういう問題ですな。

>>555
sys/cpu案は昔もあったけど、alphaやsparcみたいに一MACHINE_ARCH一MACHINEの
ポートにとっては無駄な手間なのでよけいめんどくさがられる罠。
0557名無しさん＠お腹いっぱい。2005/06/08(水) 01:58:25
MACHINEがらみもMACHINE_ARCHがらみも全部sys/archにぶち込んでるのが悪い。
sys/dev/cpuか何か作れ。
0558名無しさん＠お腹いっぱい。2005/06/08(水) 02:03:38
ﾏﾀﾞｰﾘｽﾄのネタがいっぱい出てきたな。
0559名無しさん＠お腹いっぱい。2005/06/08(水) 02:11:49
要するに x86==PC/AT という世間一般の常識を覆せるかどうか、ですよ。
Appleが新しいx86マシンを出せばそれができるかもしんない。
その中身が実はAT互換機そのまんまだったらやっぱり無理。
0560名無しさん＠お腹いっぱい。2005/06/08(水) 02:25:39
>>556
pcat 新設か、今のままかの両者の得失まで出尽くしてるんなら、あとは
決めるだけだね。決まらないんなら、誰か行動する（CVS 枝作る）。
で、行動する人は pc98 の人とか以外あり得ないと思ってたけど、
「そうでもない、pc98 以外にも恩恵ある」ってことか。
0561名無しさん＠お腹いっぱい。2005/06/08(水) 02:32:16
>>560
やるだけなんだけど、今回のコンパイラのwarning追加だけでも
コンパイルできねーよ報告でcurrent-usersその他があふれるのに、
既存のMACHINEを変えるなんて大手術をしたらしばらくはエラーが出続ける
だろうからよくわかっていない人からの苦情が殺到しそうなのがイヤよね。

NetBSD/powerpc→NetBSD/ofppcの時は誰も文句言わなかったけど、
wsはちょっとムッとしてたような。
0562名無しさん＠お腹いっぱい。2005/06/08(水) 02:58:23
>>556
MACHINE に i386 を期待される場合は sysctl で uname(3) の返事を
変える、と。
0563名無しさん＠お腹いっぱい。2005/06/08(水) 03:13:38
>>562
当時も言及されていたけど
> STANDARDS
> 　　The uname() function conforms to ISO/IEC 9945-1:1990 (``POSIX.1'').
に対してどうなのかということを見ないといけない?
0564名無しさん＠お腹いっぱい。2005/06/08(水) 03:24:10
>>560
NetBSD/pc98のコードを見る限りではアレを書いた人たちがMACHINE_ARCHとMACHINEの使い分けや
MI/MDの概念を理解して書いていたとは思い難いのでその人たちが作業するのはあり得ないと思ってたよ。
そもそもi386からのpcat分離以前にかなりのコードを書き直さないと当時の本家にマージすることすら困難。

逆の見方をすれば、移植のための材料はすべてそろってるんだからあとは
　求む!やる気のある若者
ということなんだが。
0565名無しさん＠お腹いっぱい。2005/06/08(水) 03:30:43
今時 PC9801 触ってウレシイ若者なんて... 居ないだろな..
オレでさえ 9801RX とか VX とかで Minix1.5 動いたりした方が面白いもん....
ゴメン..
0566名無しさん＠お腹いっぱい。2005/06/08(水) 03:45:06
なんでいつまで経ってもマージされないのはそういう理由だわな。
・実機が簡単に入手可能で
・ハードの仕様やブートの方法がわかっていて
・他に誰もやってない
という点では移植入門に最適なんだが、車輪の再発明っぽいところがアレだ。
0567名無しさん＠お腹いっぱい。2005/06/08(水) 03:57:43
pc98 より、FutureNet MA-4[12]0 とかに載って欲しいな。うふ。

ttp://www.centurysys.co.jp/product/ma420/index.html

...とか思ったら、IIJ がやってる?

ttp://www.seil.jp/seilengine/Installations/02.html
0568名無しさん＠お腹いっぱい。2005/06/08(水) 04:06:20
そうそう、pc98のいいところとしては
　マージされれば動かしてくれるユーザーがそれなりにいる(と思われる)
ってのがあるよ。
組み込み系はシリアルコンソールだったりして敷居高いし動いた感動もいまいち。
ものにもよるけど値段も張るしね。
0569名無しさん＠お腹いっぱい。2005/06/08(水) 04:23:16
>>565 オレでさえって、どのくらいジジイなん?
0570名無しさん＠お腹いっぱい。2005/06/08(水) 17:12:17
久々に見たらバージョン番号が3.99とかNetBSDらしからぬ進み方なんだが、
いったい何があったんだ？
あと2.xと3.xの大きな違いって何？
0571名無しさん＠お腹いっぱい。2005/06/08(水) 17:48:25
>>570
バージョン番号は釣りです。
0572名無しさん＠お腹いっぱい。2005/06/08(水) 18:19:32
起動するときに流れてくじゃん文字が
それってどっかに保存されてないの？
dmesgだと、デバイスの情報しか見れないけど
starting ほにゃらら
とかのぶんまでみたいわけ

てきとうに /var/もみたけど
わからんかった
0573名無しさん＠お腹いっぱい。2005/06/08(水) 18:47:24
>>570
http://mail-index.netbsd.org/tech-kern/2004/09/30/0020.html
0574名無しさん＠お腹いっぱい。2005/06/08(水) 18:54:45
>>572
保存されないのでシリアルコンソール使うとかビデオに録るとか
0575名無しさん＠お腹いっぱい。2005/06/08(水) 21:43:49
保存されてないんだ
保存する方法はありませんか？
0576名無しさん＠お腹いっぱい。2005/06/08(水) 21:44:33
ビデオ… いや確かにその手しかない場合もありますが(w

普通は msgbuf のサイズを増やすのが吉。
options MSGBUFSIZE=32768
かな。
05775762005/06/08(水) 21:46:56
あ、すまん読み間違えた。
カーネルの出す方じゃなくて starting なんとかの方ね。
それは >>574 の言うとおりシリアルコンソールを設定
して保存するのが、今だと一番簡単かなあ。
0578名無しさん＠お腹いっぱい。2005/06/08(水) 21:50:31
そこで本物のttyですよ！
0579名無しさん＠お腹いっぱい。2005/06/08(水) 21:53:06
よくシリアルコンソールとか聞くけど何？
0580名無しさん＠お腹いっぱい。2005/06/08(水) 21:56:05
またこいつか
0581名無しさん＠お腹いっぱい。2005/06/09(木) 00:38:36
本物の tty で... ビデオに撮るのか?
■ このスレッドは過去ログ倉庫に格納されています