Orz日記 by Akio Morita

_ [tDiary]またコメントスパムに突破された

フィルターを突破されたので設定を修正＆ログを記録してみる

投稿してるのはおそらく BOTなのですが...頑張りますねぇ Orz

_ [SAD]Cygwin対応 in amorita branch

SA_ONSTACK/SA_NOCLDWAIT機能フラグは、 SigAction関数がユーザーに提供しているだけなので、 Revision 2209にてSA_ONSTACK/SA_NOCLDWAITマクロが 未定義の場合は、当該フラグのサポートしないようにした。

具体的には、sigaction(2)に渡す環境依存フラグを組み立てるコードで 関連する部分を ifdefで無効化しています。

他のSA_*マクロが無い場合の同様の処置が可能なはずだが、 SA_SIGINFO/SA_RESTART/SA_RESETHANDに関しては SAD側の SIGFPEハンドラ等の実装に使ってるので必須です。

他の部分に関しては、昨日の日記にも書いたけど Cygwin側の POSIX機能の実装が不足しているのが原因なんで Cygwin環境側で 対処すべき問題だと思う。

ucontext_t型

sigaction(2)で、SA_SIGINFOを使えるようなので、 POSIX SA_SIGINFOなハンドラのプロトタイプ void handler(int, siginfo_t *info, ucontext_t *uap) が使えるはずなので、環境依存なucontext_t型の定義を 行うヘッダーファイルが存在するべきなのだが... Orz

また、Cygwinに getcontext(3)が存在しないとの情報も有るので、 User Thread Context自体がサポートされていないと思われる。

POSIX SA_SIGINFOなハンドラは、第3引数経由で割り込み時の User Thread Contextを受け取ることになっているので、 sigaction(2)がSA_SIGINFOなハンドラを受け入れる以上 getcontext(3)やucontext.hが未実装なのは SUSv2的に NG。

SUSv2的には、前出のSA_ONSTACK/SA_NOCLDWAIT機能フラグが 存在しないのも NGなのだが...

getaddrinfo/getnameinfo/freeaddrinfo(IPv6 API/RFC3493)

Cygwinの IPv6 APIの実装が不足している。

外部プロジェクトで、実装を 進めている人々がいるので、その成果物をインストールするか、 自前で RFC3493を実装すべし

Tcl/Tkパッチファイル名

仮想マシン上で、母艦のファイルシステムを使う場合は CIFS等の ネットワークマウントに於ける名前空間変換の問題がある。

Cygwinで NTFSをローカルマウントした際に":"キャラクタと パス名に使用できないのは、Cygwinの実装上の制限と思われる。

_ [FreeBSD][Ryzen]Ryzen Threadripper 2950X

前回の続き

SuperKEKBの運転も終わったので、検証再開 make -j16 buildworld+buildkernelの連続負荷 48時間クリア 95時間クリア (2019-07-10 22:10)

変更点

• X399M Taichi Firmware V3.50へ更新 (3.22Aから)
• ラジエーターファンの配置変更(吸い出しから吹き込みに)
• FreeBSD 12-STABLE r349722へ更新

X399M Taichi/Threadripper固有設定のまとめ

• /boot/loader.conf

efi.rt.disabled=1
machdep.hyperthreading_allowed=0

efi.rt.disabled=1 12-CURRENT系で試験し始めたころのworkaroundなので今は外せる (2019-07-10 検証)

• /etc/sysctl.conf

# Ryzen threadripper 2950X Tctl offset
dev.amdtemp.0.sensor_offset=-27
dev.amdtemp.1.sensor_offset=-27

動作温度

前扉と2.5inchケージの隙間が狭いため、SSD/HDDベイの温度の方に大きな影響が出る模様

_ [SAD]sequence utility

sequence container utilityを実装中

bsearchまで実装したので、delete操作を実装すれば、Complementは作れるはず

_ [FreeBSD][雑記]in-kernel NAT試験中

ipfw divert + natdの代わりに、ipfw in-kernel natを試験中

基本的な機能は、use_sockets/punch_fwオプションの類が無いぐらいでほぼ同じだが、微妙に挙動が違う

deny_in(deny_incoming)を指定しれないはずなのだが、divert/natd経由で観測されていたLISTENしてないポートへのincomming(攻撃) packetが見えない…

redirectしてるパケットは問題なく通信出来ている模様だが…

なにが違うのだろう？ それとも時間帯か？