ToDo:
なんか、MAIN trunkに Cygwin用の変更が入っているが、 見るからに uglyなコードですねぇ
MacOSX上の VMwareで動かす Cygwin on Windosから MaxOSX上の File Systemを見ると:が%003Aに化けるそうだが、 VMware3の頃と同様にホストOS側とゲストWindowsのFile System共有に SAMBAを使っているのなら SAMBAの HEX codingが原因に思えるのだが...
だとすると、環境側の問題なので取り込むべきでは無いよね
もしも、Cygwin上で展開したFile Name Space上の:文字が 化けるとしたら、File System層のエミュレートにバグがあることになる
WindowsのローカルなNTFSを bin modeで Cygwin側にマウントしている 状況で、Cygwinな bashからecho foo > bar:zooを実行すると barというファイルが出来る。つまり、:から先の PATH名が 無視されている。unix互換じゃないぞ!(2008-07-08追記)
以前、MacOSX上で shellからでは無く GUI付きのMacアプリな展開ツールで tar.gzを展開すると:が別の文字に変換されるという事例に 遭遇したことがある。 MacOSの PATH Separatorは :だが、unix側のAPIを使うと(unix shell等) unix API側で:と/を入れ替える変換を内部的に実施しているが、 昔ながらのMacOS API(おそらく Carbon)ではそのような変換を行わないので アプリ側が変換しているのが原因だった。
実在しないファイルの依存関係が commitされている
make dependするときは、cleanな source treeで行いましょう
uglyですねぇ...
ucontext_tに関しては、SUSv2/POSIX.1-2001辺りに有るらしいし、 sigaction(2)で POSIX SA_SIGINFOなハンドラが使える場合は 第3引数が ucontext_t*なのでその定義が必要で、 SA_SIGINFOマクロが未定義という問題が出ていない以上、 環境依存のucontext_t型を定義するヘッダーは存在しなければならないはず。 したがって、無いのは全面的に Cygwin側が悪いような気がする。
SA_ONSTACK/SA_NOCLDWAITが未定義な際に、 0以外の定数マクロを定義するのは、移植性的に NG。 フラグビットの位置は環境依存だからこそ、マクロで定義している訳で、 これを未定義だからと言って環境を考慮せず 0以外の定数にすると どんな副作用があるか分からない。
そもそも、フラグマクロが未定義ということはサポートされていないと言う ことなので、src/tfProcess_.c側で SA_ONSTACK/SA_NOCLDWAITフラグを 操作するコードを #ifdefで無効化すべきところ
IPv6をサポートするための Address Family Independent APIなのですが、 IEEE Std 1003.1-2004(POSIX.1)/RFC 3493らしいので、無いのは Cygwinが悪い。 あと、この手の未実装APIを独自の実装で置き換える場合、 移植性を考えると呼出側に埋め込まずに APIの実装を別ファイルにして リンク時に組み込みを制御すべきところ(置き場的には、src/simの下かな?)
Cygwin/w32api 1.5.25-15 IPv6 extension0.22なんてものが有るらしい。 つまり、Cygwinの libcは IPv6未対応ということ(2008-07-08追記)
WAN側のIPv6通信は確保したので、LAN側をどうするかの考察
技術的には以下のアイデアがある
一番手がかからないのはYAMAHAルーターあたりを買ってくる(ついでにMAP-EなIPv4 over IPv6トンネルも開通する)辺りだが、LAN側にDNSで引けるIPv6アドレスを割り当てるなら次点はunique local unicastによる実装か?
久々にカーネルパニック(Fatal trap 18: integer divide fault while in kernel mode)で死んだ
バックトレースからsys/netinet/libalias/alias_db.cが怪しい
KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00b27f30b0 vpanic() at vpanic+0x181/frame 0xfffffe00b27f3100 panic() at panic+0x43/frame 0xfffffe00b27f3160 trap_fatal() at trap_fatal+0x387/frame 0xfffffe00b27f31c0 trap() at trap+0x8b/frame 0xfffffe00b27f32d0 calltrap() at calltrap+0x8/frame 0xfffffe00b27f32d0 --- trap 0x12, rip = 0xffffffff808a68bc, rsp = 0xfffffe00b27f33a0, rbp = 0xfffffe00b27f33b0 --- HouseKeeping() at HouseKeeping+0x1c/frame 0xfffffe00b27f33b0 LibAliasInLocked() at LibAliasInLocked+0x2f/frame 0xfffffe00b27f3470
おそらく当該コードは stable/13 390866d47effe8f5a11f3f852ae891f14dd4d15cで導入されたHouseKeepingの起床レートを処理パケットレートに基づいて調整するコードのコーナーケースと思われる
コーディング的には、kernel modeでの経時処理が重いので可能な限り処理パケット数で起床レートを制御し、直近約1秒の処理パケット数から平均毎秒3回の起床レートとなるようpacket_limitを制御するのが目的だが、パケットレートが低い場合に穴がある模様
mainも現時点 では、治ってないぽぃ
修正は、packet_limitに下限値を設定しておく辺りか
user spaceのnatdを使っている場合は、デーモンが死んでNATが機能しなくなるものと思われる
void HouseKeeping(struct libalias *la) { static unsigned int packets = 0; static unsigned int packet_limit = 1000; LIBALIAS_LOCK_ASSERT(la); packets++; /* * User space time/gettimeofday/... is very expensive. * Kernel space cache trashing is unnecessary. * * Save system time (seconds) in global variable LibAliasTime * for use by other functions. This is done so as not to * unnecessarily waste timeline by making system calls. * * Reduce the amount of house keeping work substantially by * sampling over the packets. */ if (packets % packet_limit == 0) { time_t now; #ifdef _KERNEL now = time_uptime; #else now = time(NULL); #endif if (now != LibAliasTime) { /* retry three times a second */ packet_limit = packets / 3; packets = 0; LibAliasTime = now; } } /* Do a cleanup for the first packets of the new second only */ if (packets < (la->udpLinkCount + la->tcpLinkCount)) { struct alias_link * lnk = TAILQ_FIRST(&la->checkExpire); CleanupLink(la, &lnk, 0); } }
カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記