Nobuyoshi Sato (発信者情報開示本Booth) @[email protected]

ウマかけて先日割ったこれをどうにかします。

リモートから使えるようにしたシリアルコンソールからu-bootのFDTを書き換えたが、u-boot本体も書き換えないとアカンっぽい。

朝起きたら、奥さんが回していて出勤した洗濯機が止まっていて洗濯完了まで30分かかって、研究室に来たら来たでメインのFreeBSDマシンのxdmがXサーバごと落ちてるし、再起動してみても今度はXのキーボード入力ができねぇ。
で、xdmを起動しないようにしてOSごと再起動してxinitしたらキーボード入力を受け付けるので、xdmを起動してみたらちゃんと使える。どうなってんのこれ。

ROCK 4 SEのu-bootのFDTいじってGPIOに出てるpwmをOSから見えるようにして、pwmコマンドでデューティーをいじってもこれ。サイクルは変えられる。

とりあえず、手持ちのUSB-PDなモバイルバッテリーでROCK 4を4時間ほぼ無負荷で駆動して、どこまで減るかを見ることにした。

本番をROCK 4 SEにした時の検討をしてるんだけど、動き回る人にとりつけるのと、一晩寝てる間持つ(でもトイレにはいくかもしれない)を簡単なhackで両立するの、めんどくせぇな。

一晩寝てる間ずっと動くかどうかの試験で夕方まで6時間こいつらとお友達だがじゃますぎるな。本番ではROCK 4にする予定だけど。

トーホグだって、お盆を過ぎたらホームセンターは石油ファンヒーターを売り始めるぞ。

動くからいいかもう...。

/dev/tty*をopen(2)で開いてread(2)して、stdoutにwrite(2)してるだけのプログラムなんだが、write(2)が無限にバッファリングされる...。stdoutがつながってる先はパイプで、rubyのOpen3.popen3で作ってる。O_DIRECTとかその辺だろうけど、問題はO_DIRECTを建てたいopen(2)を呼んでるのがrubyだってことなんだな。
なお、fputc(stdout, &buf, 1); ffliush(stdout);なら確かにバッファされないが。もにょる。

１秒ごとにバッファリングされる理由が、Cで書いたヘルパーのバッファリングだったんだが。write(2)を使ってみても同じなんだな...。おかしいな。putc()してfflush()した方が確実なんだけどどうなってるんだ...。

FreeBSD上のrubyで困ってたModularEEGからシリアルで飛んでくるパケットのバイトが丸ごと落ちる問題、Cで書いたヘルパーを挟んでpopen3を使ってパイプから読むことにして解決はしたんだけど、パイプがバッファリングされてしまって１秒ごとにまとめてデータが飛んでくる感じになってしまった。

Twitterの発信者情報開示のことを考えると、増改築を繰り返したボロアパートっぷりがひどいのよ。なにしろ、スマホからのアクセスが大多数、でもスマホユーザーを全員収容するだけのグローバルIPv4アドレスはない、Carrier Grade NATのせいで投稿者に基本的にたどり着けない、だもの。無法地帯よ。

というか、インターネット自体が増改築を繰り返したボロアパートみたいなところがある。