X
dragonfly bsd どうよ
0202名無しさん＠お腹いっぱい。
垢版 |
NGNG
Cannaの報告した199です。コンパイルは問題なかったけどkterm上でshift+spaceで変換する時
四角の中の"あ"の文字が記号になって日本語の入力ができませんでした。
gcc34でコンパイルしたFreeWnnだと問題なく日本語の表示、入力ができました。
0216214
垢版 |
NGNG
とりあえずdmesgの一部を貼ってみた
pcib1: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pcib1: couldn't read bus number from cfg space
pcib1: trying bus number 1
pci1: <ACPI PCI bus> on pcib1
pcib2: <DEC 21154 PCI-PCI bridge> at device 8.0 on pci1
pci2: <PCI bus> on pcib2
fxp0: <Intel 82559 Pro/100 Ethernet> port 0xecc0-0xecff mem 0xfde00000-0xfdefffff,0xfdfff000-0xfdffffff
irq 10 at device 4.0 on pci2
installed MI handler for int 10
miibus0: <MII bus> on fxp0
inphy0: <i82555 10/100 media interface> on miibus0
inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: MAC address: 00:02:b3:xx:xx:18
fxp1: <Intel 82559 Pro/100 Ethernet> port 0xec80-0xecbf mem 0xfdd00000-0xfddfffff,0xfdffe000-0xfdffefff
irq 5 at device 5.0 on pci2
installed MI handler for int 5
miibus1: <MII bus> on fxp1
inphy1: <i82555 10/100 media interface> on miibus1
inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp1: MAC address: 00:02:b3:xx:xx:19
xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xdc80-0xdcff mem 0xfbfffc00-0xfbfffc7f irq 5 at device 12.0 on pci1
miibus2: <MII bus> on xl0
xlphy0: <3c905C 10/100 internal PHY> on miibus2
xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl0: MAC address: 00:b0:d0:xx:xx:15
0217214
垢版 |
NGNG
続き
pcib0: <Intel 82810E (i810E GMCH) Host To Hub bridge> at pcibus 0 on motherboard
pci0: <PCI bus> on pcib0
agp0: <Intel 82810E (i810E GMCH) SVGA controller> mem 0xff000000-0xff07ffff,0xf4000000-0xf7ffffff irq 9 at device 1.0 on pci0
pcib3: <Intel 82801AA (ICH) Hub to PCI bridge> at device 30.0 on pci0
pci3: <PCI bus> on pcib3
pcib4: <DEC 21154 PCI-PCI bridge> at device 8.0 on pci3
pci4: <PCI bus> on pcib4
fxp2: <Intel 82559 Pro/100 Ethernet> port 0xecc0-0xecff mem 0xfde00000-0xfdefffff,0xfdfff000-0xfdffffff irq 10 at device 4.0 on pci4
miibus3: <MII bus> on fxp2
inphy2: <i82555 10/100 media interface> on miibus3
inphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp2: MAC address: 00:02:b3:xx:xx:18
fxp3: <Intel 82559 Pro/100 Ethernet> port 0xec80-0xecbf mem 0xfdd00000-0xfddfffff,0xfdffe000-0xfdffefff irq 5 at device 5.0 on pci4
miibus4: <MII bus> on fxp3
inphy3: <i82555 10/100 media interface> on miibus4
inphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp3: MAC address: 00:02:b3:xx:xx:19
xl1: <3Com 3c905C-TX Fast Etherlink XL> port 0xdc80-0xdcff mem 0xfbfffc00-0xfbfffc7f irq 5 at device 12.0 on pci3
xl1: couldn't map ports/memory
device_probe_and_attach: xl1 attach returned 6
0219名無しさん＠お腹いっぱい。
垢版 |
NGNG
>218
ACPI切って起動したら正常に認識されました。
配布されてたCDイメージから入れたやつで unameでは1.1-CURRENTとでてます。
srcはcvsupでDragonFly-src-supfile利用して拾ってきたやつです。
何時頃やったかは忘れました。
0220218
垢版 |
NGNG
>>219
uname -aか ls -l /kernel
の結果を教えてください。ホスト名がギャルゲの名前とかになっているん
だったらそれは隠してもらっていいです。
0221名無しさん＠お腹いっぱい。
垢版 |
NGNG
uname -a が
DragonFly auaua 1.1-CURRENT DragonFly 1.1-CURRENT #0: Tue Oct 26 01:43:09 GMT 2004
root@auaua:/usr/obj/usr/src/sys/Dbsd i386
で ls -l /kernel が
-r-x-r-xr-x 1 root wheel 2947189 Oct 26 01:45 /kernel*
です。
0229220
垢版 |
NGNG
>>228 ACPIを有効にしても大丈夫なんですか?
0230228
垢版 |
NGNG
kldstatで普通にacpi.koがでてますがNICは正常に認識されています
0231名無しさん＠お腹いっぱい。
垢版 |
NGNG
Firefox入れてみたところコンパイルは問題なかったんですがxorg-vfbserver入れようとしたとき
gcc -fpcc-struct-return -c -ansi -Dasm=__asm -Wno-system-headers -I/usr/dfports/x11-servers/xorg-vfbserver/work/xc/include/fonts
-I../include -I/usr/dfports/x11-servers/xorg-vfbserver/work/xc/lib/xtrans -I/usr/dfports/x11-servers/xorg-vfbserver/work/xc
-I/usr/dfports/x11-servers/xorg-vfbserver/work/xc/exports/include -I/usr/X11R6/include -I/usr/X11R6/include -DCSRG_BASED
-DFUNCPROTO=15 -DNARROWPROTO -DTCPCONN -DUNIXCONN -DHAS_STICKY_DIR_BIT -DHAS_FCHOWN -DIPv6 -DFONT_t -DTRANS_CLIENT
-DTRANS_SERVER -DTRANS_REOPEN -DBSD44SOCKETS -DXVENDORNAME='"The X.Org Foundation"' -DXVENDORNAMESHORT='"X.Org"' -O transport.c -o unshared/transport.o
In file included from transport.c:80:
/usr/dfports/x11-servers/xorg-vfbserver/work/xc/lib/xtrans/Xtranssock.c:1378: error: `MAXHOSTNAMELEN' undeclared here (not in a function)
*** Error code 1
Stop in /usr/dfports/x11-servers/xorg-vfbserver/work/xc/lib/font/fc.
*** Error code 1
Stop in /usr/dfports/x11-servers/xorg-vfbserver/work/xc/lib/font.
*** Error code 1
Stop in /usr/dfports/x11-servers/xorg-vfbserver.
というのがでます。
CCVER?=34 X_WINDOW_SYSTEM=xorgでコンパイルしてます。
work/xc/include/Xos_r.hの430行が辺りかと思ったんですが
0232231
垢版 |
NGNG
すいません。work/xc/lib/xtrans/Xtranssock.c の94行目のOSの定義のとこに
(__DragonFly__) を追加してコンパイルしてみたら問題なくコンパイルできました。
firefoxも利用できました。
0233名無しさん＠お腹いっぱい。
垢版 |
NGNG
年末にお家鯖をリニューアルしようと思っていて、
下の三つの候補で迷ってるんだけど、

-DragonFly BSD stable
-DragonFly BSD current
-FreeBSD stable

おまいさん方なら、どれにする？
0235名無しさん＠お腹いっぱい。
垢版 |
NGNG
無難なFreeBSD stableと言いたいとこだけどここはDragonFlyのスレなので
DragonFlyで。FreeBSDのcurrentとか追いかけたことあるならcurrentで、ないならstableでいいのでは?

FreeBSD Expert2005みたらFreeBSD開発者のインタビューにDragonFlyの開発者が載っていた。
インタビュー内容の3分の2はDragonFlyBSDについてだったけど。
0236233
垢版 |
NGNG
NetBSD-currentとFreeBSD5-currentは
それぞれ一年くらい使ってた事があります。
DragonFlyはstableとcurrentってそれほど違いはないのかな？

FreeBSD Expert2005探してみる(`･ω･´)
0237234
垢版 |
NGNG
>>236
じゃあMLを見物しながらupgradeするタイミングをつかめる
(あるいは強運の持ち主)だろうから-CURRENTに決まりだね。
DragonFly_Stableはbranchではなく単なるrevision tagだから
ML上だといつ動いたのか分からないし、あとmergeが不可能だから
HEADの重要な変更をいくつかrevisionを飛び越してStableに反映、
てなことも無理なんで、自分で面倒みれるんなら-CURRENTでも
問題はなさそうだと思う。
といいつつウチのメールサーバは(uname -sはCURRENTだったころの)
Stableだけど。
0238237
垢版 |
NGNG
>>237
|といいつつウチのメールサーバは(uname -sはCURRENTだったころの)
「uname -r」だった。

ところで最近また(話題の)hsu@がネットワークまわりで修正を入れていって
いるみたいだから、いつupgradeするか悩ましいところだよね。
0242名無しさん＠お腹いっぱい。
垢版 |
NGNG
ttp://kerneltrap.org/node/view/4370
タイトル見たとき一瞬リリースのスケジュールに関することかと思ってしまったが
よく読んだらスケジューラに関する話題でした。
0247名無しさん＠お腹いっぱい。
垢版 |
NGNG
ports/archives のarc　のpatch-ab のOS定義されている2箇所に(__DragonFly__)を追加したら
コンパイルできました。これ以外でsecurity/clamav のインストールに引っかかるとこはなかったです。
環境は1.1stableでCCVERが3.4です。
0249名無しさん＠お腹いっぱい。
垢版 |
NGNG
4-STABLEの安定性を維持したまま機能拡張されるのなら既存の4.x系サーバの管理者にとって
DraonFlyBSDは重要だと思うが、そうじゃなくてもう一つのCURRENT branchだから、
4系のFreeBSDの開発が終了するのとはあまり関係がないような。
0250名無しさん＠お腹いっぱい。
垢版 |
NGNG
安定を求める人は結局5系列が安定するまで4系列にパッチ当てて使い続けると思う。
DragonFlyが4系列にとって変わるくらいの安定性を持つなら5系列と取って代わると思う。
0251名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>249
|4-STABLEの安定性を維持したまま機能拡張されるのなら

このデマどこで聞いたの? スラッシュドットあたり?
0254名無しさん＠お腹いっぱい。
垢版 |
NGNG
>251
>249 じゃないけど、一応 Interop BOF だったかで hsu が発表したときには
安定性・後方互換性を重視して FreeBSD 4.x をコードベースに
採用したし、今後もその点は大事にしたいとは言ってたよ。

ただし目指している方向性からみても字面通りに捉えるのは
無理がある気はするけど。
0255名無しさん＠お腹いっぱい。
垢版 |
NGNG
>>254
hsuといえば昨年末から「cleanup」と称してガシガシやってるみたいだけど、
commitlogのこういう行数を見ると、どこかにバグが潜んでいる気がするよ。

1.10 +283 -354 src/sys/net/route.c
0258名無しさん＠お腹いっぱい。
垢版 |
NGNG
>255
ほとんど入れ替えだな、それ。

まあ新興勢力がチビチビとしかいじっていなかったら
fork した意味がないんでガンガンとガンガッて欲しいですね。
安定性は... しばらくは眼をつむるんじゃないかな、やっぱ。
0260255
垢版 |
NGNG
>>259
そう、大抵はそうなので
$ cvs di -wB -D'commitの数秒前' -D'commitの数秒後'

でみてみるとほとんど差分が出ないはずなんだけど彼の場合cleanupといいつつ
他の修正も混ぜちゃってるから恐い。
0270名無しさん＠お腹いっぱい。
垢版 |
05/02/03 21:25:40
うちの会社のhttpdのログ見てると、ごくまれにUA がdragonflyからのアクセスがあるけど
よっぽど暇なんだね。今日もきてた。 Mozilla/5.0 (X11; U; DragonFly ia64; en-US; rv:1.8a2) なやつ。
0278名無しさん＠お腹いっぱい。
垢版 |
05/02/16 02:34:15
ところで誰かベンチしたのだろうか
誰もしてないのなら、やってみるつもりだが

で、ベンチするとしたら
>>36にあるworker_mpmのapacheを使う方法以外になにか無いかな
0284277
垢版 |
05/02/20 22:55:06
>>280-281 ネタ?
現状のDragonFlyはi386でしか動かない。
TARGET_ARCH=amd64はコンパイルできない。
TARGET_ARCH=ia64は存在しない。
64bit機上で32bitシステム(=i386)を動作させた場合、uname -mはi386と出る。
0288名無しさん＠お腹いっぱい。
垢版 |
05/02/24 00:59:13
ソースも見ないで恐縮ですが、lockからmessageベースに移行すると
スレッドをまたがるglobalなデータはどうやって効率よく共有するんですか?
同期messageでgetter/setter呼出し、なんてのはずいぶん大変そうな気がしますが。
0289名無しさん＠お腹いっぱい。
垢版 |
05/02/24 01:48:32
>>288
それは共有データの大きさとか処理内容とかCPUをまたがっているかどうかに
もよるんじゃない?
このあたりは読んだ? ttp://www.dragonflybsd.org/goals/threads.cgi
0290名無しさん＠お腹いっぱい。
垢版 |
05/02/24 13:17:17
読んだけど、よくわからなかったり。

vfsをマルチスレッド化すれば、スレッドを跨がるデータは当然いっぱいでてきますよね。
それはmutexなりで排他制御するしかないとすると、やっぱりmessageベースといえども
マルチスレッドの諸々のコストから完全には逃れられないんですか?
0291名無しさん＠お腹いっぱい。
垢版 |
05/02/24 16:31:22
素人考えなんだけど、カーネルの機能をブロックで区切って
globalなデータを局所的なものにすためのmessage機構なんじゃないの？
マイクロカーネルでOSの機能をユーザー空間に出しても、個々のサーバーは
複数のスレッドでもって走るんでしょ？それと同じかと。
0292名無しさん＠お腹いっぱい。
垢版 |
05/02/24 20:29:02
ファイルシステムはパフォーマンスの都合上マルチスレッドにせざるを得ないと思うし、
そうなればデータをスレッド内で局所化するのは難しいと思う。
0293名無しさん＠お腹いっぱい。
垢版 |
05/02/25 00:00:03
一般論だが、複数のプログラム(スレッド)が同じファイルをオープン(操作)していなければそれほど競合資源はないはず。ページキャッシュ管理と空きブロック管理くらい。
0294名無しさん＠お腹いっぱい。
垢版 |
05/02/25 01:45:21
>>293
292 でもないし, 一般論でもないが, おれは,
複数のプログラム(スレッド)が, 同じファイルを mmap する
プログラムをしばしば書く.
0295名無しさん＠お腹いっぱい。
垢版 |
05/02/25 09:13:55
>>934
一般論だが、VFS(vnode)が問題になるのはmmapするときとページイン/アウトのとき。
複数スレッドでmmap syscallを頻繁にするか、メモリが逼迫してなければOK。
1プロセス内複数スレッドでmmapした場合はprocが問題になるとおもう。
0296名無しさん＠お腹いっぱい。
垢版 |
05/02/25 10:06:37
むしろ 4.4BSD の lookup 操作のロッキングプロトコルが
MPフレンドリーじゃなくて、Tru64 あたりではプロトコル
を変更したって話が Vahalia 本に載ってなかった？
新着レスの表示
レスを投稿する

ニューススポーツなんでも実況