コグノスケ

プロフィール更新

新会社に転籍しましたのでプロフィール更新しました。新会社の発足日にも関わらず、公式サイトが未だにお葬式状態なのですが、どういうことなの…。

さよならパナソニック

2015年 3月 1日をもってソシオネクストに転籍しました。さよならパナソニック。

ソシオネクストは、富士通セミコンダクターとパナソニックの SLSI 設計部門を合併させ、ファブレス（工場部門は既に分離済み）として再出発した会社です。

従業員は人事、経理などを除いてほぼ全員が転籍者です。出向と違い、元の会社に戻ることはありません。資本は富士通（4割）、パナソニック（2割）、日本政策投資銀行（4割）がソシオネクストに出資しています。

しかし、いずれの会社とも連結対象ではありませんので、赤字になっても救いの手はありません。反面、親会社の意向を気にせず自由に投資できます。たぶん…。

メモ: 技術系？の話は Facebook から転記（※）しておくことにした。

アイドル

自作 ARM エミュレータのアイドル状態を実装して、何もしていないのに CPU 時間をバカ食いしていた問題を解決しました。

ARM9 コアをアイドル状態に移行させるには、mcr 命令を使ってコプロセッサ 15 の特定のレジスタにストアします。具体的に言うと mcr 15, 0, r0, cr7, cr0, {4}（opcode_1:0, crn:7, rd:0, opcode_2:4, crm:0）です。ただ、これだけ実行すれば良いものでもないので、詳細は Linux の arch/arm/mm/proc-arm926.S の cpu_arm926_do_idle という関数が参考になります。

アイドル状態に入ると CPU は停止し、デバイスから割り込みが掛かると再開します。実装する前は簡単かなーと思っていたのですが、やってみると意外と大変でした。

今まで割り込み回りの実装をサボっていて、CPU からデバイスの割り込みステータスを全力でポーリングするだけのやっつけ処理しか実装しておらず、デバイスから CPU に何か通知する仕組みが全くなかったためです。

どう見ても自業自得ですね。うん。

Intel とモバイル端末

PC Watch - Intel、3G/LTE統合型SoC「Atom x3 C3000」シリーズを読んで。

個人的には Intel の SoC は携帯端末向けと言いつつ、PC としても使えます！という作りにした方が輝くと思いますが、その路線も、単純に攻めるのはもう限界とも思います。

というのも PC として使おうとすると、どうしてもある程度の画面サイズ（出力手段）と、キーボード（入力手段）が欲しくなるからです。

Baytrail が 8〜 インチタブレットを捉えたので、単純に考えれば次に狙うのは 7インチ以下のタブレットですが、7インチの画面は PC としては小さすぎますし、キーボードも端末の倍近いサイズになって非常に格好悪いです。

出力手段は、画面を折るとか重ねるとか何とかするにしても、入力手段だけはキーボード以外でキーボード以上の正確さと速さを持つものを見つけないと、ミニ画面 PC を実現するのは、ちょいと厳しそうですね…。

メモ: 技術系の話は Facebook から転記しておくことにした。

SysV init の処理変更

何となく自分ではわかっているつもりでしたが、いざ変更しようとしたら全然わかっていなかった init の話です。

突然ですが Linux マシンのブート時にやりたいことが増えた場合、どうやって変えたら良いでしょうか？SysV init なら /etc/inittab か /etc/init.d/rcS を変えれば？とサラりと答えられる方は、きっとかなり詳しい方ですね。

せっかく書くので、初めて見る人でもわかるように……とまでは言いませんが、Linux のブート時には何が実行されるのか？を 1つずつ見ていこうと思います。

init 以前

Linux カーネルは起動が終わると、PID 1 のプロセスとして、下記リストを上から順に実行しようとします（参考: linux/init/main.c の kernel_init() 関数）。

• カーネルの引数 init= に指定したパス
• /sbin/init
• /etc/init
• /bin/init
• /bin/sh

通常の利用では init= を指定しないと思いますので、/sbin/init が実行されるはずです。Debian では（※）これが System V init を指しています。

（※）Debian に限らず昔は SysV init が多かったのですが、最近は Ubuntu の upstart、Gentoo Linux の openrc、Fedora Core の systemd のように、SysV init 以外の init も増えています。設定の方法が皆違うので、同時に使うと混乱します……。

init と inittab

SysV init は /etc/inittab という設定ファイルに従って動作します。この inittab というファイルには runlevel がいくつのときは、こういう動作をしなさい、という命令が羅列されています。

ちなみに runlevel とは SysV init の動作モードのことで、大抵は 0〜6, S の 8つのモードがあります。実際に使われるのは 3〜4個（0: マシン停止、1: シングルユーザ、2 や 3: デフォルト、6: マシン再起動）だったりしますけど。デフォルトの runlevel はディストリビューションによって違います。たぶん 2 が多いんじゃないかな。

例として Debian GNU/Linux 7.8(Wheezy) の /etc/inittab を見てみます。

# The default runlevel.
id:2:initdefault: ★デフォルトの runlevel★

# Boot-time system configuration/initialization script.
# This is run first except when booting in emergency (-b) mode.
si::sysinit:/etc/init.d/rcS ★runlevel に無関係に、システムブート中に実行される。★

(...略...)

l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2 ★runlevel 2 なら、ここが実行される★
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6

(...略...)

Debian の場合、まず最初に /etc/init.d/rcS が実行され、その後、デフォルト runlevel の 2 に対応する /etc/init.d/rc 2 が実行される、ということがわかります。ちなみに /etc/init.d/rcS は、下記のような実装です。

#! /bin/sh
#
# rcS
#
# Call all S??* scripts in /etc/rcS.d/ in numerical/alphabetical order
#

exec /etc/init.d/rc S

すなわち、init は /etc/init.d/rc S と /etc/init.d/rc 2 を実行しているだけです。ここまでの話をまとめておくと、

前提: ディストリビューションは Debian GNU/Linux 7.8(Wheezy) 

1. Linux Kernel 起動終盤に kernel_init() が /sbin/init を起動

2. /sbin/init は /etc/inittab を見る

3. /etc/inittab には init への指示が書いてある
  3-1. デフォルトの runlevel は 2 である
  3-2. ブート時に /etc/init.d/rcS を実行せよ
    3-2-1. /etc/init.d/rcS は /etc/init.d/rc S を起動する
  3-3. runlevel 2 なら /etc/init.d/rc 2 を実行せよ

こうなります。割とシンプルですよね。

/etc/init.d/rc

簡単に言えば /etc/rcXXXX.d ディレクトリの中に入っている初期化スクリプトを全部実行するランチャーです。XXXX の部分には rc の第一引数に指定した runlevel が入ります。例えば rc S であれば /etc/rcS.d/* が、rc 2 であれば /etc/rc2.d/* が実行されます。

スクリプトの先頭から中程にかけて色々と環境変数を設定していますが、注目すべきは、CONCURRENCY という変数です。rc はこの CONCURRENCY という変数の値によって大きく動作が変わります。

#
# Check if we are able to use make like booting.  It require the
# insserv package to be enabled. Boot concurrency also requires
# startpar to be installed.
#
CONCURRENCY=makefile
test -s /etc/init.d/.depend.boot  || CONCURRENCY="none"
test -s /etc/init.d/.depend.start || CONCURRENCY="none"
test -s /etc/init.d/.depend.stop  || CONCURRENCY="none"
if test -e /etc/init.d/.legacy-bootordering ; then
        CONCURRENCY="none"
fi
if ! test -e /proc/stat; then
        if [ "$(uname)" = "GNU/kFreeBSD" ] ; then
                # startpar requires /proc/stat
                mount -t linprocfs linprocfs /proc
        fi
fi
startpar -v > /dev/null 2>&1 || CONCURRENCY="none"

条件を洗っていくと、下記のいずれかが成立するとき CONCURRENCY=none となり、いずれも成立しなければ CONCURRENCY=makefile となることがわかります。

• /etc/init.d/.depend.boot が存在しないか、空ファイル
• /etc/init.d/.depend.start が存在しないか、空ファイル
• /etc/init.d/.depend.stop が存在しないか、空ファイル
• /etc/init.d/.legacy-bootordering が存在する
• startpar -v コマンドが失敗する

次に CONCURRENCY の役割について調べるため、rcXXXX.d 内のスクリプトを実行するための startup() という関数を見てみます。

#
# Start script or program.
#
case "$CONCURRENCY" in
        makefile|startpar|shell) # startpar and shell are obsolete
                CONCURRENCY=makefile
                log_action_msg "Using makefile-style concurrent boot in runlevel
 $runlevel"
                startup() {
                        eval "$(startpar -p 4 -t 20 -T 3 -M $1 -P $previous -R $
runlevel)" ★1

（略）

        none|*)
                startup() {
                        action=$1
                        shift
                        scripts="$@"
                        for script in $scripts ; do
                                $debug "$script" $action ★2
                        done
                }
                ;;

色々書いてありますが、簡単に言うと
CONCURRENCY=makefile であれば、startpar を起動（★1）し、
CONCURRENCY=none であれば startup() に渡された引数を一つずつ起動する（★2）、という作りです。

次に呼び出し側も見てみます。

# Now run the START scripts for this runlevel.
# Run all scripts with the same level in parallel
CURLEVEL=""
for s in /etc/rc$runlevel.d/S* ★1
do
        # Extract order value from symlink
        level=${s#/etc/rc$runlevel.d/S}
        level=${level%%[a-zA-Z]*}
        if [ "$level" = "$CURLEVEL" ]
        then
                continue
        fi
        CURLEVEL=$level
        SCRIPTS=""
        for i in /etc/rc$runlevel.d/S$level* ★2
        do
                [ ! -f $i ] && continue
                
                (...略...)

                SCRIPTS="$SCRIPTS $i" ★3
        done
        startup $ACTION $SCRIPTS ★4
done

まず ★1 にある * のパターン展開一発で、起動するべきスクリプトが「起動順に列挙」されます。

理由は 2つで、/etc/rcS.d 中のファイルは全て「S + 2桁の数字 + 名前.sh」という規則でファイル名が付けられていること、なおかつ、bash は * の展開結果をアルファベット順にソートする仕様（下記を参照）だからです。

   パス名展開
       -f オプションが指定されていなければ、単語分割を行った後に bash はそれぞ
       れの単語が *, ?, [ を含んでいるかどうか調べます。  これらの文字のいずれ
       かが見つかると、その単語は  パターン  とみなされ、 パターンにマッチする
       ファイル名を アルファベット順にソートしたリストに置換されます。  マッチ
       ...

次に ★2 から ★3 の間の処理で、同じレベルのスクリプト名を列挙して全て連結し、★4 で startup() にスクリプト名を渡して実行します。ちなみに runlevel S および 2 のときの ACTION 変数には "start" が入っています。

例えば S10zzz.sh S20aaa.sh と S20bbb.sh と S30ccc.sh があったとしますと、

• startup start S10zzz.sh
• startup start S20aaa.sh S20bbb.sh
• startup start S30ccc.sh

このような順に startup() が呼ばれることになります。

前提: ディストリビューションは Debian GNU/Linux 7.8(Wheezy) 

1. Linux Kernel 起動終盤に kernel_init() が /sbin/init を起動

2. /sbin/init は /etc/inittab を見る

3. /etc/inittab には init への指示が書いてある
  3-1. デフォルトの runlevel は 2 である
  3-2. ブート時に /etc/init.d/rcS を実行せよ
    3-2-1. /etc/init.d/rcS は /etc/init.d/rc S を起動する
  3-3. runlevel 2 なら /etc/init.d/rc 2 を実行せよ

↑↑↑↑↑ 以上、おさらい 1 の部分 ↑↑↑↑↑

4. 下記がいずれか一つでも成立すれば CONCURRENCY=none 成立しなければ CONCURRENCY=makefile
  - /etc/init.d/.depend.boot が存在しないか、空ファイル
  - /etc/init.d/.depend.start が存在しないか、空ファイル
  - /etc/init.d/.depend.stop が存在しないか、空ファイル
  - /etc/init.d/.legacy-bootordering が存在する
  - startpar -v コマンドが失敗する

5. /etc/rcXXXX.d/S* をアルファベット順に実行
   CONCURRENCY=none ならば、単に実行するだけ、
   CONCURRENCY=makefile ならば、startpar に起動を任せる

SysV init の処理変更（直列版）

昨日（2015年 3月 5日の日記参照）に引き続き、何となく自分ではわかっているつもりでしたが、いざ変更しようとしたら全然わかっていなかった init の話です。

まずは SysV init の動きのおさらいから。

前提: ディストリビューションは Debian GNU/Linux 7.8(Wheezy) 

1. Linux Kernel 起動終盤に kernel_init() が /sbin/init を起動

2. /sbin/init は /etc/inittab を見る

3. /etc/inittab には init への指示が書いてある
  3-1. デフォルトの runlevel は 2 である
  3-2. ブート時に /etc/init.d/rcS を実行せよ
    3-2-1. /etc/init.d/rcS は /etc/init.d/rc S を起動する
  3-3. runlevel 2 なら /etc/init.d/rc 2 を実行せよ

↑↑↑↑↑ 以上、おさらい 1 の部分 ↑↑↑↑↑

4. 下記がいずれか一つでも成立すれば CONCURRENCY=none 成立しなければ CONCURRENCY=makefile
  - /etc/init.d/.depend.boot が存在しないか、空ファイル
  - /etc/init.d/.depend.start が存在しないか、空ファイル
  - /etc/init.d/.depend.stop が存在しないか、空ファイル
  - /etc/init.d/.legacy-bootordering が存在する
  - startpar -v コマンドが失敗する

5. /etc/rcXXXX.d/S* をアルファベット順に実行
   CONCURRENCY=none ならば、単に実行するだけ、
   CONCURRENCY=makefile ならば、startpar に起動を任せる

さて、お忘れの方も多いかと思いますが、本題は「init の処理に何か足したい」でした。

もし CONCURRENCY=none つまり直列版の init を使っている場合、init に何か足す方法は非常に簡単です。今まで見てきたように、/etc/rcS.d 以下にスクリプトファイルを足せば、/etc/init.d/rcS が実行してくれます。

SysV init の処理変更（並列版）

しかし CONCURRENCY=makefile つまり並列版の init を使っている場合、/etc/rcS.d 以下にスクリプトファイルを足すだけでは実行されません。なぜかというと startpar というコマンドが一枚噛んでいるためです。

この startpar というコマンドには 2つのモードがあります。

NAME
       startpar - start runlevel scripts in parallel

SYNOPSIS
       startpar [-p par] [-i iorate] [-t timeout] [-T global_timeout] [-a arg]
       prg1 prg2 ... ★1
       startpar [-p par] [-i iorate] [-t timeout]  [-T  global_timeout]  -M  [
       boot|start|stop] ★2

一つは ★1 側の、渡された引数を実行する CONCURRENCY=none に近い動作をするモード（引数に -M を指定しない）です。
もう一つは ★2 側の、別の設定ファイルからスクリプトの依存関係を得て、出来る限り並列に実行する（引数に -M を指定する）モードです。

さて /etc/init.d/rc では、startpar の 2つモードのうち、どちらが使われていたでしょうか？覚えている人はスゴい暗記力です。私も含めて忘れてしまった方のために、もう一度コードを見ます。

#
# Start script or program.
#
case "$CONCURRENCY" in
        makefile|startpar|shell) # startpar and shell are obsolete
                CONCURRENCY=makefile
                log_action_msg "Using makefile-style concurrent boot in runlevel
 $runlevel"
                startup() {
                        eval "$(startpar -p 4 -t 20 -T 3 -M $1 -P $previous -R $
runlevel)" ★1

簡単ですね。別の設定ファイルを見る（-M を指定する）モードです。しかもよく見ると startup() に渡されているスクリプト名（$2 以降の引数）は無視されています。だから /etc/rcS.d/ にスクリプトを足すだけでは、実行されなかったのです。

startpar の設定ファイル更新

では startpar に何か処理を追加するには、何をどうしたら良いのか？と言う話です。こういうときはまず startpar のマニュアルを見てみます。

       The -M option switches startpar into a make(1)  like  behaviour.   This
       option takes three different arguments: boot, start, and stop for read-
       ing .depend.boot or .depend.start or .depend.stop respectively  in  the ★1
       directory  /etc/init.d/.  By scanning the boot and runlevel directories
       in /etc/init.d/ it then executes the appropriate scripts in parallel.

FILES
       /etc/init.d/.depend.boot
       /etc/init.d/.depend.start
       /etc/init.d/.depend.stop

SEE ALSO
       init(8) insserv(8). ★2

★1 の説明を見るに、-M は boot, start, stop のうちどれか 1つ引数を取って、実際の動作は .depend.boot or .depend.start or .depend.stop で決まりますよ、というようなことが書いてあります。親切なことに FILES の章にファイルのフルパスまで書いてくれています。

これら 3つの .depend.XXXX ファイルを更新すれば良い、ということがわかりましたが、どうやって更新するのかが書いていなくて困ってしまいます。とりあえず ★2 の SEE ALSO の章にある insserv という奴が新顔で怪しいので、マニュアルを見ます。

INSSERV(8)                                                          INSSERV(8)

NAME
       insserv  -  boot  sequence organizer using LSB init.d script dependency
       information

(...略...)

FILES
       /etc/insserv.conf
              configuration file for insserv  which  defines  the  LSB  System
              Facilities.

(...略...)

       /etc/init.d/.depend.boot,
       /etc/init.d/.depend.start,
       /etc/init.d/.depend.stop
              The make(1) like dependency files produced by insserv for  boot‐
              ing, starting, and stopping with the help of startpar(8). ★1

コマンドの説明はちょっと抽象的でわかりづらいですが、FILES の ★1 の部分を見る限り、探し求めていた物に間違いないでしょう。

1. /etc/rcS.d/ に S20script.sh のような名前のスクリプトを追加する

2. startpar -M を使っている場合は、insserv を実行して設定ファイルを更新する

まとめてしまえば短いものですが、これも init の仕組みの一端だと思うと、中々に感慨深いもんがありますね。

ファミコンの CPU

昨日の飲み会でファミコンの CPU が Z80 だって大嘘ついてしまった……。

正解は MOS 6502（の互換 CPU、リコー製）です。

覚えていたら月曜に訂正しておこう。

メモ: 技術系の話は Facebook から転記しておくことにした。

GPS は世界一正確な時計

GPS のレシーバーモジュールを買いました。Globalsat BU-353S4 という USB 接続の製品で、Amazon で 5,000円くらいです。

買った理由ですが、別に家の位置を知りたかったわけではなく、NTP サーバのクロック源にしてみたいと思ったからです。

NTP の時刻同期方法

NTP というのは PC やサーバの時刻を合わせるためのプロトコル（Network Time Protocol）のことです。NTP サーバとは NTP を使った時刻合わせの機能を提供するサーバのことです。

普通の人は公開されている NTP サーバを使うので、自分で NTP サーバは立てませんが、マシンがたくさんあるような場所（会社、学校など）では、全員が一気に公開 NTP サーバにアクセスすると、NTP サーバの持ち主に迷惑（サーバがダウンしたり、回線が埋まって動作不能になる）になります。

自分マシン 1 <-- 同期 --+--> 自分 NTP サーバ <-- 同期 --> 公開 NTP サーバ
自分マシン 2 <-- 同期 --+
...                     |
自分マシン n <-- 同期 --'

公開 NTP サーバと同期させたネットワーク内の 1台のみを自分 NTP サーバとして、他のマシンは自分 NTP サーバと同期させることで、公開 NTP サーバに掛かる負荷を軽減させます。

ここでふと疑問に思ったのが、公開 NTP サーバが無かったら、自分 NTP サーバはどうやって正しい時間を取ったら良いの？ということです。

調べてみると NTP サーバは様々な時計から、時刻を取得できる（NTP のクロックドライバのドキュメント）ようです。良くできてます。

その中でも GPS が割と接続も、設定も簡単そうだったので、試してみることにしました。

GPS として使ってみる

買ってきた GPS モジュールを Linux マシンに繋ぐと下記のようなメッセージが出ます。どうやら GPS モジュールは PC から見ると単なるシリアルポート /dev/ttyUSB0 として扱われている（★1）ようです。

usb 4-2: new full-speed USB device number 2 using uhci_hcd
pl2303 4-2:1.0: pl2303 converter detected
usb 4-2: pl2303 converter now attached to ttyUSB0 ★1
usb 4-1: new full-speed USB device number 3 using uhci_hcd

シリアルポートに入力されてくる文字列を見ても意味不明なので gpsd というソフトに意味を理解して貰います。gpsd を起動する前に、設定ファイルへ先ほどカーネルログに出ていたシリアルポートを指定します（★2）。

Debian では /etc/default というディレクトリの下に設定ファイルが集まっていて、gpsd の設定ファイルもそのディレクトリにあります。

# Default settings for gpsd.
# Please do not edit this file directly - use `dpkg-reconfigure gpsd' to
# change the options.
START_DAEMON="true"
GPSD_OPTIONS=""
DEVICES="/dev/ttyUSB0" ★2
USBAUTO="true"
GPSD_SOCKET="/var/run/gpsd.sock"

設定が終わったら /etc/init.d/gpsd start として gpsd を起動します。何もメッセージが出なくて不安になる方は、ps ax | grep gpsd として、起動しているかどうか見ると安心できると思います。

さらに、衛星との通信状況などグラフィカルに表示してくれる xgps というナイスなソフトをインストールし、起動してみます。

apt-get install gpsd-clients

xgps

画面イメージは下記のようになりますが、室内かつ部屋の前には廊下があるせいか、ほとんど GPS 信号を受信できていません……。

xgps の動作イメージ

残るは NTP サーバの設定ですが、続きはまた今度。

着眼点の差

Publickey - HTML5 Canvas に JavaScript でリアルタイムに動画を描画。透過レイヤで動画の重ね合わせなど、新たな表現が可能な PC／モバイル対応コーデック「H2MD」を読んで。

重ねることを前提とした新しい動画コーデック H2MD の紹介記事。

圧縮率がーとか、画質がーとか、そういう誰でも思いつく（※）勝負に行かないところが、さすがアクセル……。

※誰もが考えてくるから競争が激しくコストがかかるうえ、従来の倍とか、そんなレベルで圧勝しない限り評価が曖昧で勝ち負けがよく分かりません。

メモ: 技術系の話は Facebook から転記しておくことにした。

New エディタ

最近、サクラエディタに代えて、GitHub の開発した Atom エディタと、もう一つ GVim を試しています。

使い慣れないエディタは思い通りに動かないので、エディタの良し悪しに関わらず、非常にイライラします…。

Atom エディタ

動作速度は悪くないのですが、起動が遅いのと、メモリを結構使う（起動するだけで 200MB 以上）ので、VirtualBox + ブラウザ + Atom と立ち上げると、会社の標準 PC（3GB）の空きメモリ量が残念なことになります。

家のノート PC（4GB）なら多少の余裕があります。もしくは仮想マシンを諦めれば、余裕があるのかな、でも、開発で使っているので何ともし難い。うーん…。

GVim

ほぼ一瞬で起動しますし、軽くて良いです。画面の再描画処理がおかしいのか、画面がバシバシ瞬くことがあって、目が痛いです。

初見では「Vim だよコレ！」と思いましたが、文字をマウスで選択できたり、ウインドウ幅をマウスで変えられるようで、ちゃんと GUI してます。もちろんコマンド（^W < や >）でも変えられますけど。

今のところ、サクラエディタと Atom ではできていた「ドラッグ＆ドロップすると新たなタブが開く」ができなくて困っているのですが、おそらく何か解決方法があるんだろう…。