技術者見習いの独り言

続・tar(1) はなぜオプション引数にハイフンが不要なのか？―tarとkey argumentsの起源を更に辿る

2024-06-28T01:12:00.015+09:00

TL;DR

CTSS bulletin 44 を見よ

また、過去ではなく未来方向、つまり Bell Lab で Unix の successor として生まれた Plan 9 や Inferno における tar についてはこちらで lufia 氏がまとめておられたので参考にどうぞ。Plan 9とInfernoにおけるtar(1)の変化

Introduction

前回の記事では、tar(1)が Unix v1 (1971) のtap(1)まで遡ること、また、その引数は key というサブコマンドの原始的な姿のようなものだったことを調査した。

さて、実は Unix v1 Programmer's Manual の栄えある最初のページを飾るコマンドは今でもスタティックリンクライブラリの作成などで使われる ar(1) であり、こちらも tar 同様に key を受け取ることになっており、引数の形態が tar(1) と大変良く似ている。また、tar(1)と異なり、ar(1)は登場から 53 年、ずっと名前が変わってない。

こうなると次は、「tar(1),tp(1),tap(1)やar(1)に見られる『key』という引数形態はいったいどこからやってきたのだろう」ということが気になってくるのである。

Unixの源流

Unixで出てきた概念やコマンドの多くはたいてい、Unixが全くの初出ではなくMulticsで既に構想・設計された概念であることが非常に多い。

たとえば ken (Ken Thompson) や dmr (Dr. Dennis M. Ritchie) と同様に、Multics と Unix v1 どちらにも係わっている人物である jfo (Joseph “Joe” F. Osanna, Jr.) は、「ベル研究の特許出版物のための文章作成・組版システムを作る」という名目でUnixを作るための研究豫算と計算機をぶんどってきた功績と、そしてその組版ツールであるroff(7)の作者として著名だが、roff(7)は元々 Multics で RUNOFF と呼ばれたコマンドから来ている。[1][2]

同様に、Unixの現代のVimやNeovimに繋がるviエディタの祖先、ed(1)は Multics の QED に遡る。こちらは、RUNOFF と異なり Multics 版の作者も Unix ed(1) と同じく ken である。

Multicsとアーカイバ

では、実際に Multics の System Programmer's Manual を見ていこう。中に、BX.9.04 archive Command, 06/11/68, Solomon Ohayonという節がある。

[..]
Usage

    archive key name (segl...segN)

name is the name of the archive segment and may be a
pathname relative to the root or to the working directory.
each segment of the list, segl...segN is the entry name
of a segment in the archive segment name.

SegI (a member of the list seg1...segN) may not be a pathname
and is assumed to be in the same directory (or to be placed
in the same directory) as name.

key indicates what action archive should take and may
be one of d,r, or x.
[..]

もう答えが出たようなものだが、ar(1)やtar(1)のコマンドラインインターフェースの由来は完全にここだろう。

ちなみに、マニュアルで作者として記載されている S. Ohayon は当時 MIT に居た、主に Multics のコマンド実装担当をしていた人物「Solomon Ohayon」のようだ [multicians][4]。

では、同様にテープ向けのアーカイバコマンドも存在するのだろうか。残念ながらマニュアルにあるのは PL/1 言語のテープアクセス・操作用の API と、システム配布用やバックアップ用のそれぞれのテープフォーマットの記載ぐらいしか存在しない。しかし、General Electric が計算機と Multics から手を引いたことによってその事業を継承した HoneyWell から、最終的に商用として発売された Multics の顧客向けドキュメントが存在しており、インターネット上にそのスキャンが残っている。

Name: tape_archive, ta
SYNTAX AS A COMMAND

ta key table_path {args}

FUNCTION

performs a variety of operations to create and maintain a set of files on magnetic
tape.

ARGUMENTS

key
    is one of the key functions described below.
table_path
    is the pathname of a segment created and maintained by tape_archive to serve as
    a table of contents for the archive. If the table segment does not exist, it is
    created by the append operation or the direct interactive mode.
args
    are additional arguments or control arguments as required by the particular key
    chosen (see below).

LIST OF EXTRACT OPERATIONS

x
    Usage: ta x table_path {components} {-control_arg}

    extracts from the archive[..]
[..]

http://www.bitsavers.org/pdf/honeywell/large_systems/multics/AG92-06B_multicsCmds_Nov87.pdf

しかしながら、実際に商用製品として Multics が発売されたのは Unix v3―v4 がリリースされたごろの 1973 年中であり、上記ドキュメントに「1985」とあるとおり、実際に 80 年代半ばまで市場に供給されていたとのこと。[myths]

よって、Unix などに影響され後からコマンドが拡充された可能性は十分高く（ta ほか多くのコマンドが省略形を持っていることも含めて）、Unix v1 以前から tape archiver が Multics コマンドにあったと断じることはできないと思われる。

Multicsの源流……？

さて、こうなると次は Multics の archive が更に遡ることができないか、である。~~しかし、筆者はこれ以上時代を遡っても原型らしきものは出てこないと考えている。~~註・追記(2024/06/28)： CTSS リリース時のコマンドには存在しないが、後に拡張されたコマンドに源流らしきものを発見した。

CTSS

註４で多少触れているが、Multics の中心人物として MIT から参画した Prof. Fernando J. Corbató は Compatible Time-Sharing System (CTSS) という世界最初期のタイムシェアリングシステムの作者であり、Multics は CTSS の直接の後継となる。 Unix のroff(7) そして Multics の RUNOFF は CTSS の RUNOFF に由来している。

CTSS はなにに対して Compatible かというと、IBM 709 で動いていた FORTRAN Monitor System (FMS) という、ロードされた複数の FORTRAN プログラムを連続実行するバッチシステムであり、さらにその前を辿るとそもそも人間が帳簿で計算機利用を管理し、手動でパンチカードをマシンにくべていく「人間バッチシステム」である。つまり、OS のもっとも原始的なものにまで辿りついてしまい、当然 FMS にはタイムシェアリングシステムのような高級なコマンド群はない。

1961 年の CTSS が公開された当時、CTSS はタイムシェアリングシステムではあるものの、用意されているコマンドは load や start や fap (FORTRAN Assembly Program) や mad (Michigan Algorithm Decoder)[5] など元の FSM がバッチシステムでやっていたことをオンラインでやるような仕組みのためのコマンドであり、Multics が新境地を拓いたような、現代の OS 環境で想像されるような「生活空間」を提供するようなシステムではない。Multics はそれほどに革新的、かつ野心的だったとも言えるが、CTSS の最初のデモからコマンドがどんどん拡充されており、Multics との連続性を伺わせる（RUNOFF と TYPESET も後から追加されたもののひとつ）。

CTSS bulletin 44

MITでDARPAの資金を受けて組織されたProject MACにはMAC-M-などの符号で様々なメモランダムが残されている。CTSS に関しては、CTSS bulletin という名前でいくつかメモランダムが残っていおり、そのうち CTSS bulletin 44 というメモランダムを参照すると、

New command: ARCHIV
A. Summary
    [..]
B. Format ARCHIV key NAM CLASS ALPHA BETA ...
    key = C
        comines file ALPHA CLASS, BETA CLASS, etc. into a
        simple file NAM CLASS
    key = P
        prints file(s) ALPHA CLASS contained into NAM CLASS
    key = T
        prints a table of contents of the file NAM CLASS
    key = D
        deletes the first file ALPHA CLASS encountered in the
        file NAM CLASS
    key = X
        extracts and creates the file ALPHA CLASS from NAM
        CLASS
    key = R
        replaces in the file NAM CLASS the old version of
        ALPHA CLASS by a new one consiting of the file ALPHA
        CLASS
C. [..]

とあり、ar(1) や tar(1) がサブコマンド的に key を受け取るのも、key の function letter が t, x, r, c などであるのも、はっきりここ由来だろう。更に言えばこのコマンドでは key は本当にサブコマンドとして空白区切りで渡されているように見える。

CTSS におけるテープアーカイバ

Multics の時点で tape_archive コマンドはあとから追加されたもののように推測できるので、CTSS でどうだったかを追うのはあまり意味はないが、一応裏取り。

図1: CTSS における disk memory control システムのうち、ディスク編集プロシージャの様子

マニュアルによれば、図１.のように編集した内容や出力結果を数週間、あるいは数ヶ月テープに保存しておく仕組みはあるようだが、任意にテープリールをユーザーが指定してそこに一気にファイルを書き出すような仕組みはおそらく CTSS には存在しない。そもそも現代的なファイルシステムにつながるシステム自体が、Ken Thompson が Multics、そして Unix で設計・実装した仕組みである。[6]（ただし、ディテクトリで階層化されたファイルシステムは Multics 発祥だが、ファイルの概念自体は CTSS で導入されている）

註

[1] man page は未だにroffで組版されるが、なぜか POSIX にroffは入ってない。また、現代に使うには少々厳しい文法を持っているが、俄かに信じ難いことに『プログラミング言語Go』の原書はtroffで組版されている。[3]

[2] このUnixとroffの関係と経緯故か、GNUのgroffのmanのHISTORYセクションが異様に詳しい。

[3] そもそも Go 言語の最初期の作者たちは Robert “Rob” Pike、Dr. Brian W. Kernighan、Ken Thompson、いずれもベル研でUnix や Plan 9 OS、Inferno OS、Limbo 言語などに係わっていた人材で今はGoogleに勤めている。

[4] 当時 MIT は Prof. Fernando J. Corbató を筆頭に、Project MACの一部として Multics 開発に参画していた。Prof. F.J. Corbató は世界最初期のTime-Sharing Systemのひとつ「CTSS」を作った功績で知られる。Project MAC は DARPA の資金でバックアップされており、複数人が同時に計算機リソースを使えるようにする OS 研究と、Prof. Marvin L. Minsky & Prof. John McCarthy が率いる AI 研究が併存していた。後者の AI Lab は FSF の創始者、Richard M. Stallman を輩出している。現在の MIT CSAIL の源流。参照しているドキュメントも CSAIL の Prof. Jerome “Jerry” H. Saltzer がやっているプロジェクトからきている。ちなみに Prof. Saltzer こそ CTSS の RUNOFF と TYPESET を作成した人物である。

[5] FAP のアセンブリ言語と MAD は CTSS の記述にも利用されたようだ。

[6] 冒頭に触れた QED も、当時としては「計算機環境の中で完結してプログラム・コードを編集する、つまりオン・ラインで編集できる、ということで比較的画期的だった。ただし Multics オリジナルではない。「An online editor」という題で「オンライン編集」という概念がわざわざ論文として紹介されるほどであり、1974 年の初めてベル研の外に Unix を公表した論文でもこの「An online editor」が引用されている。オリジナルの QED は Berkley SDS-930 [7]で実現されており、ken は元々 UC Berkley 出身である。このことから名前と仕様を借りて独自実装を作ったのだと思われる。

[7] Berkley SDS-930 は Berkley 独自のタイムシェアリングシステムだが、ここや後継の SDS-940 で採用された仕組みが現在の fork(2) システムコールの動作モデルと仕組みの原点である。https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/

tar(1) はなぜオプション引数にハイフンが不要なのか？

2024-06-27T06:55:00.005+09:00

TL;DR

tar(1)の引数はオプションではなくkeyだから

歴史

tar(1)は Unix v7 (1979) で導入されたが、その前身は Unix v4 (1973) の tp(1)、更にこれは Unix v1 (1971) の tap(1) に遡る。

80年代に入りSystemV v.s. BSDといったことが起きたりし、PWB/UNIX (Programmer's WorkBench)で導入された cpio(1)とtar(1)、どちらがUnixの標準アーカイバか争われた結果、IEEE Std. 1003.1-2001 (POSIX.1-2001) を以って tar(1)は規格から削除され、代わりに IEEE Std 1003.2-1992 で導入された折衷案のpax(1)が標準となった。よって、現在実装中立なtar(1)の仕様書がそもそも存在しない。最後の中立規格は1997―1998年策定のSUSv2 (UNIX V98) の仕様となる。

ちなみに、Unix v4 は C 言語が導入されカーネルやコマンドが全面的にアセンブリから C に書き直された歴史的なリリースで、PWB/UNIXは Unix v6 を fork して世界最大のユーザーを抱えるサイトとしてベル研究所内部で運用された Unix バージョン。様々な開発者向けのコマンドが開発されたようだ。たとえばバージョン管理システムの祖先、sccs(1)はPWB/UNIXが初出。（なぜかこちらは、DEVELOPMENT コマンドという註釈つきで現行の IEEE Std. 1003.1-2017 な POSIX に残っている。）

仕様

tap(1) の頃から一貫して、


NAME            tap  --  manipulate DECtape

SYNOPSIS        tap  [ key ] [ name ... ]

DESCRIPTION     tap saves and restores selected portions of the
                file system hierarchy on DECtape. 
[..]
                The function portion of the key is specified by
                one of the following letters:
                   r  The indicated files and directories,
[..]

と説明がされている。SUSv2 のtar(1)では、


 NAME
     tar - file archiver (LEGACY)
 SYNOPSIS

     tar key [file...]

 DESCRIPTION
     The tar utility processes archives of files. Its actions are controlled by the key operand.
 OPTIONS
     None.
 OPERANDS
     The following operands are supported:
     
     key
         The key operand consists of a function letter followed immediately by zero or more modifying letters. The function letter is one of the following:
[..]

となっており、tap(1)の頃からあまり大差はない。

tar(1)におけるkeyとは。なぜサブコマンドではないのか。

tar(1)における key というのは r、x、t、u、c いずれかの機能（つまり、Update、eXtract、Createなど)をまず指定し、続けて空白を入れずにfオプションだったりvオプションだったり、挙動を指定するオプション引数を続ける、ひとかたまりの文字列ということになっている

現代ならこれは

tar extract -v -f example.tar

のようにサブコマンド指定とそれに対してのオプション、というように引数を設計するだろう。また、PWB/UNIXでは既に導入されていたsccs(1)では既にサブコマンドのあるコマンドが導入されている。

しかしながら、全面的にPDP-11のアセンブリで記述されていた Unix v1 の頃からある tar(1)（の前身）では高度な引数解析を持つ実装が用意されなかったのだろう。それがそのまま、現代にも引き継がれてしまっている。

結果として、tar(1)はサブコマンドのつもりで一文字目に function letter を指定し二文字目以降にオプション文字を並べる、ひとつの文字列として key string を受け入れる、という他の Unix コマンドとやや毛色の違うオプション仕様になってしまっている。

現代のtar実装

FreeBSD

FreeBSD RELEASE 14.1 の man page https://man.freebsd.org/cgi/man.cgi?tar(1) を見るに、

NAME
       tar -- manipulate tape archives

SYNOPSIS
       tar [bundled-flags <args>] [<file> | <pattern> ...]
       tar {-c}	[options] [files | directories]
       tar {-r | -u} -f	archive-file [options] [files |	directories]
       tar {-t | -x} [options] [patterns]

function letter であってもハイフンつきのオプションとして、最初のオプションに指定することで挙動を指定するのが正則で、key string での指定は bundled-flags という名前で歴史的互換性のための指定方法ということになっている。

このあたり、function それぞれで指定できるオプションの種類などがmanを一瞥しただけで理解できる書き方になっていてとてもわかりやすくて良い。

なお、-c指定のときに-fを指定しなかった場合、/dev/sa0 (FreeBSD)や/dev/st0 (Linux)がデフォルト指定されることになっており、現代でも今なお、TapeARchiveというコマンドの由来の残り香がある。

GNU

このあたり、GNU Tar 1.35 (2023/08/22) でも大差はない。https://www.gnu.org/software/tar/manual/html_node/basic-tar-options.html#basic-tar-options

つまり、--create --verboseや-c -vなどのように、ハイフンつきfunction letterを最初にもってきてその後に個別オプションを指定する、という書き方がまず説明されており、key string はあくまで歴史的互換性で残されているもののようだ。

ただし、--file, -fについての扱いは FreeBSD とはやや異なる。指定をしなかったときのデフォルト指定はTAPE環境変数の指定に従うことになっており、この環境変数が指定されていなかった場合の挙動はコンパイル時に設定されているデフォルト設定に従うことになっている。https://www.gnu.org/software/tar/manual/html_node/file-tutorial.html#file-tutorial

たとえば、tar --show-defaultsの実行結果として以下の出力だったとしたとき

$ tar --show-defaults
--format=gnu -f- -b20 --quoting-style=escape
--rmt-command=/etc/rmt --rsh-command=/usr/bin/rsh

デフォルトで -f-が指定されているので、特に何も指定していなくても勝手に標準入力や標準出力を使ってくれる、ということになる。このあたり、完全に各 distribution で作成されているパッケージのビルドオプション次第ではあるものの、大抵の環境では -f- が指定されていることが期待できそうな気がする。

追記

Unix v1 のその先の源流をさらに辿ってみた続編を書きました。 https://orumin.blogspot.com/2024/06/tar1-tarkey-arguments.html

また、過去ではなく未来方向、つまり Bell Lab で Unix の successor として生まれた Plan 9 や Inferno における tar についてはこちらの lufia 氏のブログでまとめてもらってます！ Plan 9とInfernoにおけるtar(1)の変化

Gitで複数のブランチで並列して扱うべんりな方法

2023-08-24T01:44:00.002+09:00

タイトルどおりのトピックです

Gitには便利なことにgit-worktree(1)が存在する。しかし、普通にgit-cloneしてきたレポジトリの中でgit-worktreeで他のブランチをチェックアウトしてくると、当然だがgitとしてはそのチェックアウトしてきた別のブランチのあるディレクトリがまるっとuntracking filesに出てきて、大変ジャマなことこの上ない、という欠点があるのである……

解決方法

git-clone(1)にはいくつかcloneの方法がある。--mirrorや--bareなどである。今回は--bareを取り上げる。

mkdir my_project
cd my_project
git clone --bare [email protected]/orumin/my_project .bare

このようにcloneすると、my_project/.bare配下にgitのレポジトリ本体だけがcloneされる。レポジトリで管理されているファイル群やコミットも全てgitレポジトリでgit objectとして管理されている状態にのみなっており、ファイルの実体はどこにもcheckoutされていない状態となる

cd my_project
echo "gitdir: .bare" > .git
git worktree add main

こうすると、実際はgitレポジトリではないmy_projectディレクトリ直下に居るときでもgitレポジトリとしてgitコマンドが認識してくれるので、git-worktree(1)も利用できる状態となっている。この場合、ここでgit worktree add mainをすることで、my_project/mainというディレクトリにorigin/mainのブランチがcheckoutされて、gitで管理しているファイル群にアクセスできるようになる。同様に、他のブランチに関してもmy_project直下でgit worktree addすればディレクトリの形でぽこぽこブランチがcheckoutできる、というわけである。

また、

git worktree -b add_new_feature feature_branch origin/main

などとすれば、origin/mainをベースとして新規ブランチadd_new_featureを切り、これをfeature_branchというディレクトリ名でworktreeを作成してくれる。べんり！

remote branchをfetchできない！

以上でよいように思うが、git-pullなどをするとき途端に困った事実に直面する。remote branchをfetchできないのである。これは、--bareではなく普通にgit-cloneするときに設定される値が、git clone --bareでは設定されないためである。

git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"

簡単に言えば、この設定を追加すればoriginとして設定しているremote repositoryに対してgit-fetchしたときちゃんとlocal repositoryに紐付けてダウンロードしてくれるようになる。これで、オールオッケー！

ブランチごとにディレクトリを作成する……？

でもこれってSVNみたいじゃないですか？

はい……でも便利だし……

C言語でRAII

2022-05-20T01:03:00.004+09:00

前置き：RAII って？

C++ 言語には RAII; Resource Acquisition is Initialization という考え方があります。これはどういうことでしょうか。

#define ARRY_SZ (5)
int32_t p_arry = (int32_t *)malloc(sizeof(int32_t) * ARRY_SZ);
p_arry[0] = 1;
p_arry[1] = 2;
p_arry[2] = 3;
p_arry[3] = 4;
p_arry[4] = 5;

for (size_t idx=0; idx<ARRY_SZ; ++idx) {
    printf("p_arry[%zu]=%" PRId32 "\n", idx, p_arry[idx]);
}

よくある、Cでヒープ確保するコードですが、このコード片は free(p_arry) を呼び出し忘れているため、もしかしたらメモリーがリークするかもしれません。また、for 文で値を表示する前に p_arry[n] = n+1; の形式で確保した領域を初期化していますが、ここで初期化を忘れていたらどうでしょう。未初期化の領域を読み出そうとするのは Undefined Behavior なので、鼻から悪魔が出るかもしれません。

#include <cstddef>
#include <cstdint>
#include <cstdio>
#include <cinttypes>
#include <new>
#include <initializer_list>

class HeapArray {
private:
    std::int32_t *values = nullptr;
    std::size_t size = 0;
public:
    HeapArray() = delete;
    HeapArray(std::initializer_list<std::int32_t> init) {
        this->values = new(std::nothrow) std::int32_t[init.size()];
        if (this->values == nullptr) {
            return;
        }
        this->size = init.size();
        std::size_t idx=0;
        for (auto&& v : init) {
            this->values[idx] = v;
            ++idx;
        }
    }
    ~HeapArray() { delete[] this->values; };
    void debug() {
        for (std::size_t idx=0; idx<this->size; ++idx) {
            std::printf("values[%zu]=%" PRId32 "\n", idx, this->values[idx]);
        }
    }
};

int main() {
    HeapArray test {1, 2, 3, 4, 5};
    test.debug();
    return 0;
}

ではこちらの C++ のコードはどうでしょう。クラスにしておくことで、先程の C のコードとやってることは同じですが、変数宣言するだけでコンストラクタでヒープ確保をしますし、スコープから外れたら自動でデストラクタが呼ばれてヒープが開放され、また、初期化子リストなしで変数宣言するとデフォルトコンストラクタが delete してあるのでコンパイルが通らないので、プログラマに初期化を強要できます。

prog.cc: In function 'int main()':
prog.cc:36:15: error: use of deleted function 'HeapArray::HeapArray()'
   36 |     HeapArray test_2;
      |               ^~~~~~
prog.cc:13:5: note: declared here
   13 |     HeapArray() = delete;
      |     ^~~~~~~~~

このようなコンパイルエラーになるわけですね。

今回はやってませんが、ここで更に unique_ptr などスマートポインタ使うともっと良いかもしれませんね。

そもそも std::int32_t *values = new std::int32_t[5] {1, 2, 3, 4, 5}; とかやれば new だけで領域確保と初期化を同時にできるだろ、とかは目を瞑ってください……。

RAII によるリソース管理、他の言語にもあったりします。たとえば Pyton の with 構文。

with open("file.txt") as f:
    print(f.read())

この場合、open(2) で確保したリソースが変数 f に紐付いて管理されて、with 構文のインデントブロックのスコープから外れると、自動で close(2) が裏で呼ばれてリソースが開放されます。close 呼び忘れがなくてめっちゃ便利ですね。

C で RAII

C プログラマーはこのようなイディオムの恩恵に与れないのでしょうか。いえ、実はコンパイラ拡張によっては、このような書き方も可能になるのです。

#include <stddef.h>
#include <stdint.h>
#include <stdlib.h>
#include <stdio.h>

static inline void dtor(void *p) {
    free(*(void **)p);
    puts("freed!");
}

#define ARRY_SZ (5)

int main() {
    __attribute__((cleanup(dtor))) int32_t *p_arry = (int32_t *)malloc(sizeof(int32_t)*ARRY_SZ);
}

それがこの __attribute__((cleanup(func))) です。一見このコードは p_arry に格納したヒープがリークしてそうですが、実はちゃんと dtor 関数が呼ばれています。その証拠に、このコードをコンパイル・実行するとコンソールに freed! と表示されるはずです。

ところで、このコードだと確保した領域は未初期化のままです。そこで、次のようにしてみます。

#include <stddef.h>
#include <stdint.h>
#include <inttypes.h>
#include <starg.h>
#include <stdlib.h>
#include <stdio.h>

static inline void ctor(int32_t *p, size_t sz, ...) {
    va_list ap;
    va_start(ap, sz);
    for (size_t idx=0; idx<sz; ++idx) {
        p[idx] = va_arg(ap, int32_t);
    }
    va_end(ap);
}

static inline void dtor(void *p) {
    free(*(void **)p);
    puts("freed!");
}

#define CTOR_HEAP_ARRY(var, sz, ...) \
__attribute__((cleanup(dtor))) int32_t *var = (int32_t *)malloc(sizeof(int32_t)*sz); \
ctor(var, sz, __VA_ARGS__)

#define ARRY_SZ (5)

int main() {
    CTOR_HEAP_ARRY(p_arry, ARRY_SZ, 1, 2, 3, 4, 5);
    for (size_t idx=0; idx<ARRY_SZ; ++idx) {
        printf("p_arry[%zu]=%" PRId32 "\n", idx, p_arry[idx]);
    }
}

どうでしょうか！ヒープ確保と共に初期化もできましたよ！やりましたね！

ここで用意したマクロを使ってもらえなかったらどうするの、とか、そもそもこのマクロ結構危険じゃない？とか、いろいろ言いたいこともあると思います。initializer list でやるようなことを可変長引数で実現しようとしてエラーチェックもサボってるので、バッファオーバーランの危険性もあります。だめですね。

はい。みんな Rust とか使おうね。

としぁ Adventしたね Calendar 2022 #toshi_a解凍 22日目

2022-04-26T19:35:00.000+09:00

今度こそ遅刻しないとか思ってたけど普通に遅刻したし特にネタも思い浮かばなかったので、としぁさん初対面の時の思い出でも書きます。

mikutter というものを知ったのは 2010 年かそこらに、Ruby で書かれた Linux でも使えるクライアントがあるらしいことを聞いていたのですが、そのときはたぶん Windows メインの利用者で Ruby はむしろ導入ダルそうだったので、たぶん Tween とか使ってました。

懐しいですね Tween。

そのあと、FreeBSD や Arch Linux とか使い出して mikutter も普段使いしはじめて、TL 大破させられたのは前 https://orumin.blogspot.com/2022/04/toshia-tl-advent-calendar-2022-toshia-6.html に書いたとおり。

そのあと、2014 年、なんやかんやで Google Summer of Code とか参加して、そのネタで syuu1228 先生と一緒に OSC Kansai@Kyoto のブース出したんですよね。

そこでコード書いてたら、いきなりにやにやしながら mikutter シールを束で目の前に叩き付けた人がやってきてですね、そうです、としぁさんと生で会ったはじめてのタイミングでした。

SNS 上の振舞い・発言と裏腹にリアルではすごい真面目な感じで、という人は結構居そうですが、としぁさんリアルでもヤベーよと思って笑ったの覚えています。

なんやかんやでそこから 8 年も経ってるし、OSC Kansai も今は OSC 大阪や OSC 京都になってるんでしたっけ。時間経つの早いですねぇ。

toshi_a に TL 大破されてから８年と４ヶ月経ちました― としぁ Adventしたね Calendar 2022 #toshi_a解凍 6日目（遅刻）

2022-04-07T02:52:00.006+09:00

2021年の年始に引越してからこのブログ更新しわすれていたことに気付きました。

え、マジ？

私事ですがそれから今までなんと就労しはじめるなど個人的に大きな変化があったのでそのうちなんか書きます。

本題

Twitter から UserStream が消え mikutter で TL 大破させられ煮え湯を飲まされた @toshi_a も凍結し、ここ何年も toshi_a を青い鳥のタイムラインで見ることはなくなっていました。

凍結したtoshi_a (出典：「1991年、エッツィ（アイスマン）のミイラ化した遺体を調べる登山家のラインホルト・メスナー氏（右）と仲間」、PHOTOGRAPH BY PAUL HANNY, GAMMA-RAPHO/GETTY、NATIONAL GEOGRAPHIC より)

しかしなんと４年と数ヶ月ぶりに解凍されたということでこれを記念した toshi_a Advent カレンダーとしての記事がこちらになります。

4/6 担当ですがいつもどおり無事一日遅れました。

タイトル通りですが、toshi_a の凍結は４年前かもしれないですが、toshi_a に TL を大破されたのはなんと８年前なんですね。許さない。

いつまでこのネタひっぱるんだよ、と言われる気がしますが、気にしないことにします。

toshi_aに壊された当時のタイムライン

ちょうどあのぐらいから Twitter の人に一部認知されたり、その後ておくれと言われたりするようになったのですが、

わたしはておくれではない
真の元祖ておくれ toshi_a の帰還を歓びましょう！

これが言いたかったことです、無事 Twitter に真のておくれが帰ってきたことを思い出しましょう！

Type 3 フォントが埋め込まれた古い PostScript データになっている論文をそこそこ綺麗な PDF にする

2020-11-25T16:52:00.001+09:00

これを使う。CTAN: Package pkfix

以下利用例（論文ではないけれど）

$ pkfix-helper Lions\ -\ 1977\ -\ Lions\'\ Commentary\ on\ UNIX®\ 6th\ Edition.ps lions-helper.ps
Reading Lions - 1977 - Lions' Commentary on UNIX® 6th Edition.ps ... done.
Total number of Type 3 fonts encountered: 16
Bitmapped fonts are typeset at 300 DPI.
Finding character widths ... done.
Reading TFM files ... done (103 TFMs in 193 scaling variations).
Matching fonts:
    Processing Fn ... done (cmsl10 @ 1X, mismatch=0.53898).
    Processing Ff ... done (cmtt10 @ 1X, mismatch=0.19819).
    Processing Fg ... done (cmbx12 @ 1X, mismatch=0.36583).
    Processing Fi ... done (cmbx10 @ 1X, mismatch=0.42627).
    Processing Fk ... done (cmti10 @ 1X, mismatch=0.20169).
    Processing Fj ... done (cmbx12 @ 1.2X, mismatch=3.41283).
pkfix-helper: Best match for Fj is rather poor
    Processing Fe ... done (cmssi10 @ 1X, mismatch=0.37342).
    Processing Fo ... done (cmr17 @ 1X, mismatch=0.12955).
    Processing Fb ... done (cmsl10 @ 1.2X, mismatch=0.10469).
    Processing Fm ... done (cmr10 @ 1X, mismatch=0.20941).
    Processing Fp ... done (cmbx12 @ 2.0733X, mismatch=4.04419).
pkfix-helper: Best match for Fp is rather poor
    Processing Fc ... done (cmr12 @ 1.2X, mismatch=0.25500).
    Processing Fl ... done (cmsy10 @ 1X, mismatch=0.06818).
    Processing Fh ... done (cmmi10 @ 1X, mismatch=0.06707).
    Processing Fa ... done (cmtt12 @ 1.7283X, mismatch=1.23894).
pkfix-helper: Best match for Fa is rather poor
    Processing Fd ... done (cmmi7 @ 1X, mismatch=0.00003).

$ pkfix lions-helper.ps ../lions-fixed.ps
PKFIX 1.7, 2012/04/18 - Copyright (c) 2001, 2005, 2007, 2009, 2011, 2012 by Heiko Oberdiek.
*** Font conversion: `cmtt12' -> `CMTT12'.
*** Font conversion: `cmsl10' -> `CMSL10'.
*** Font conversion: `cmr12' -> `CMR12'.
*** Font conversion: `cmmi7' -> `CMMI7'.
*** Font conversion: `cmssi10' -> `CMSSI10'.
*** Font conversion: `cmtt10' -> `CMTT10'.
*** Font conversion: `cmbx12' -> `CMBX12'.
*** Font conversion: `cmmi10' -> `CMMI10'.
*** Font conversion: `cmbx10' -> `CMBX10'.
*** Font conversion: `cmbx12' -> `CMBX12'.
*** Font conversion: `cmti10' -> `CMTI10'.
*** Font conversion: `cmsy10' -> `CMSY10'.
*** Font conversion: `cmr10' -> `CMR10'.
*** Font conversion: `cmsl10' -> `CMSL10'.
*** Font conversion: `cmr17' -> `CMR17'.
*** Font conversion: `cmbx12' -> `CMBX12'.
*** Merging font `CMSL10' (2).
*** Merging font `CMBX12' (3).
==> 16 converted fonts.
==> 2 merged fonts.

$ ps2pdf lions-fixed.ps lions.pdf

利用したデータはこちらより > Commentary on the Sixth Edition UNIX Operating System

ここで配布している PDF はビットマップフォントが埋め込まれているのでちょっと悲しい。まあ LaTeX ソースも配布しているのでここから PDF 作るので十分なのですが、ほかにも Mach や L4 あたりの 90 年代の論文とかけっこう PostScript しかデータがないやつがいるので、それをビットマップで読むのはなにか悲しかったのでこういう方法を探していたとさ。

時刻取得・時間計測

2020-11-25T14:12:00.011+09:00

本稿では，Linux カーネルで扱える時計のうち，PTP（Precision Time Protocol）という IEEE 1588 で策定されている高精度な時計をクロックソース[1]にする場合について追っていこうと思います。

Linux における時刻同期：NTP と PTP

Linux や Windows，macOS といった現在の OS のシステムクロックは，一般的にはインターネットを通じて NTP（Network Time Protocol）が同期するようになっています。
NTP を使っていればインターネットに接続されている際には大きく時刻がズレることはなく，たまにネットワーク接続が失われていてもクォーツ時計は安物の振り子式ほど時間はズレません。

では，NTP は設計としてどのくらいの誤差が考えられているのでしょうか。NTP の設計者 David L. Mills 博士は自身が実装した PDP-11 向けの OS「Fuzzball」上の実験でそれを示しており，答えは数十ミリ秒です[2]。現代のマシンと OS ならば数ミリ秒までは迫れるかもしれません。ちなみにこの論文が発表された翌年には NTP version 2 が RFC から発行されています[3]。（現在は version 4。）

NTP は日常的な利用には十分な精度があります。しかし，マイクロ秒やナノ秒といった単位での高精度さが目的ではありません。日本の NTP のサーバーとして有名な NICT（情報通信研究機構）は日本標準時の決定をしており原子時計も所有していますが，インターネットを介して NICT などのサーバーにアクセスしている時点でミリ秒やひどいときは数秒の遅れが発生するでしょう。LAN に NTP サーバーがあったとしても，アルゴリズムとして数ミリ秒の遅延を許容しています。そこで高精度な時刻同期のために存在するのが PTP です。

PTP とは

PTP とは，ネットワークデバイス内の時計を高精度に同期する仕組みです。グランドマスタークロックと呼ばれる時計をマスターとして設置し，LAN の NIC たちがそれを元に同期するといったような仕組みになります。これによって，パケットのタイムスタンプをハードウェアで高精度に打つことが可能になったり，この PTP をクロックソースとしてシステムクロックを同期したりできます。

ixgbe と PTP

Intel の 10GbE のネットワークインターフェイスとして，ドライバ名から ixgbe と呼ばれるものがあります。Intel 82599 や Intel X540 などが該当します。今回は Intel X550[4 sec. 7.7]について追っていこうと思います。

前準備・Intel アーキテクチャと割り込みについて

ソースコードを追う前にまず，PCIe 機器はどのように CPU に接続されどのように扱われるかを知らなければなりません。

図１．Intel アーキテクチャと割り込みの関係についてのブロックダイアグラム図

Intel CPU はおおむね上図のような形になっています[5 sec. 10.1]。大昔は Intel 8259 という割り込みコントローラーが直接 CPU に接続されて，周辺機器の割り込み信号は全部このコントローラーに接続されていましたが，現在では CPU の各コアに Local APIC という割り込みコントローラーがあり，チップセットのほうに割り込み I/O APIC という割り込みコントローラーがあります。このように分離されているおかげで，周辺機器からの割り込み信号は I/O APIC が受け取ってからどのコアに割り込みを配送するか自由に設定できますし，コア同士の通信は Local APIC を通じて IPI を送ることで可能となっています。

PCI デバイスは I/O APIC へ割り込み信号を送ることも可能ですが，もうひとつ，MSI という割り込みも可能です[6 sec. 6.8]。これは，割り込みコントローラーのピンに割り込み線を接続して INTx で割り込む（pin-based 割り込み）のではなく，デバイスにメモリに直接割り込みメッセージを書くことによって CPU コアの Local APIC へ割り込みが送られます。

MSI での割り込みは pin-based の割り込みと違い，ピンが少なくてすんだりパフォーマンス上有利だったりとメリットが多く，また，PCIe デバイスでは MSI やその拡張である MSI-X が必須になっています。

ソースコードを読もう

今回は v4.17-rc7 のソースコードを読みます。ixgbe のソースコードは，drivers/net/ethernet/intel/ixgbe/にあります。以下断わりなくソースコードのファイル名を出した場合はこのディレクトリを起点に考えてください。

Linux のクロックソースとして ixgbe の PTP を設定するとなると，ixgbe のエントリポイントで割り込みベクタを設定する部分を読む必要がありそうです。そこで，irq や msix といった割り込みに関連しそうな処理をエントリポイントから探してみます。

まずはエントリポイントそのものを探さなければなりません。ixgbe_main.cといういかにもなソースコードから entry point という語で探すと，6584 行目，ixgbe_open()が見つかります。

int ixgbe_open(struct net_device *netdev)
{
     struct ixgbe_adapter *adapter = netdev_priv(netdev);
     struct ixgbe_hw *hw = &adapter->hw;
      int err, queues;

     /* disallow open during test */
     if (test_bit(__IXGBE_TESTING, &adapter->state))
         return -EBUSY;

     netif_carrier_off(netdev);

    /* allocate transmit descriptors */
     err = ixgbe_setup_all_tx_resources(adapter);
     if (err)
         goto err_setup_tx;

     /* allocate receive descriptors */
     err = ixgbe_setup_all_rx_resources(adapter);
     if (err)
         goto err_setup_rx;

     ixgbe_configure(adapter);

     err = ixgbe_request_irq(adapter);

このコードの 6088 行目でixgbe_request_irq(adapter);という呼び出しがあります。この関数は，同じソースコードに短い定義があります。3418 行目です。

static int ixgbe_request_irq(struct ixgbe_adapter *adapter)
 {
     struct net_device *netdev = adapter->netdev;
     int err;

     if (adapter->flags & IXGBE_FLAG_MSIX_ENABLED)
         err = ixgbe_request_msix_irqs(adapter);
     else if (adapter->flags & IXGBE_FLAG_MSI_ENABLED)
         err = request_irq(adapter->pdev->irq, ixgbe_intr, 0,
                   netdev->name, adapter);
     else
         err = request_irq(adapter->pdev->irq, ixgbe_intr, IRQF_SHARED,
                   netdev->name, adapter);

     if (err)
         e_err(probe, "request_irq failed, Error %d\n", err);

     return err;
 }

3424 行目に ixgbe_request_msix_irqs(adapter) がありますね。ここで MSI-X の割り込みを登録しているのではないか，と推測されますね。では，実際に確かめます。同一ファイル 3274 行目。

static int ixgbe_request_msix_irqs(struct ixgbe_adapter *adapter)
  {
      struct net_device *netdev = adapter->netdev;
      unsigned int ri = 0, ti = 0;
      int vector, err;

      for (vector = 0; vector < adapter->num_q_vectors; vector++) {
          struct ixgbe_q_vector *q_vector = adapter->q_vector[vector];
          struct msix_entry *entry = &adapter->msix_entries[vector];

          if (q_vector->tx.ring && q_vector->rx.ring) {
              snprintf(q_vector->name, sizeof(q_vector->name),
                   "%s-TxRx-%u", netdev->name, ri++);
              ti++;
          } else if (q_vector->rx.ring) {
              snprintf(q_vector->name, sizeof(q_vector->name),
                   "%s-rx-%u", netdev->name, ri++);
          } else if (q_vector->tx.ring) {
              snprintf(q_vector->name, sizeof(q_vector->name),
                   "%s-tx-%u", netdev->name, ti++);
          } else {
              /* skip this unused q_vector */
              continue;
          }
          err = request_irq(entry->vector, &ixgbe_msix_clean_rings, 0,
                    q_vector->name, q_vector);
          if (err) {
              e_err(probe, "request_irq failed for MSIX interrupt "
                    "Error: %d\n", err);
              goto free_queue_irqs;
          }
          /* If Flow Director is enabled, set interrupt affinity */
          if (adapter->flags & IXGBE_FLAG_FDIR_HASH_CAPABLE) {
              /* assign the mask for this irq */
              irq_set_affinity_hint(entry->vector,
                            &q_vector->affinity_mask);
          }
      }

      err = request_irq(adapter->msix_entries[vector].vector,
                ixgbe_msix_other, 0, netdev->name, adapter);

割り込みベクタを登録していると思しき関数呼び出し，request_irq() が二箇所ありますね？これはそれぞれどういうことでしょう。ひとつめの request_irq() （3298 行目）は 3280 行目からのイテレーターの中にあります。このイテレーターではデバイスの構造体である adapter にある q_vector というものをイテレートしているようです。

/* MAX_Q_VECTORS of these are allocated,
 * but we only use one per queue-specific vector.
 */
struct ixgbe_q_vector {
    struct ixgbe_adapter *adapter;
#ifdef CONFIG_IXGBE_DCA
    int cpu;        /* CPU for DCA */
#endif
    u16 v_idx;      /* index of q_vector within array, also used for
                 * finding the bit in EICR and friends that
                 * represents the vector for this ring */
    u16 itr;        /* Interrupt throttle rate written to EITR */
    struct ixgbe_ring_container rx, tx;

    struct napi_struct napi;
    cpumask_t affinity_mask;
    int numa_node;
    struct rcu_head rcu;    /* to avoid race with update stats on free */
    char name[IFNAMSIZ + 9];

    /* for dynamic allocation of rings associated with this q_vector */
    struct ixgbe_ring ring[0] ____cacheline_internodealigned_in_smp;
};

adapter->q_vector のデータ構造の定義を ixgbe.h から探してみるとこのようになっていることから，送受信のためのキューとその設定の構造体でしょう。ひとつの adapter に複数 q_vector が登録できるのはマルチキューのためですかね。さて，ixgbe_request_msix_irqs()に戻ってみてみると，3284 行目から 3294 行目までの条件分岐で vector が rx.ring か tx.ring かを見ているため，これが，送受信のためのリングバッファが作られているのならそれに関連した割り込みベクタを登録しているのだということが推測できます。時計の処理には関係なさそうなので，もうひとつの request_irq() をみてみましょう。

3313 行目のもうひとつの request_irq() では ixgbe_msix_other という関数の名前を持ってきています。この関数はやはり同じソースコード，ixgbe_main.c の 3109 行目に存在しています。

static irqreturn_t ixgbe_msix_other(int irq, void *data)
  {
      struct ixgbe_adapter *adapter = data;
      struct ixgbe_hw *hw = &adapter->hw;
      u32 eicr;

      /*
       * Workaround for Silicon errata.  Use clear-by-write instead
       * of clear-by-read.  Reading with EICS will return the
       * interrupt causes without clearing, which later be done
       * with the write to EICR.
       */
      eicr = IXGBE_READ_REG(hw, IXGBE_EICS);

      /* The lower 16bits of the EICR register are for the queue interrupts
       * which should be masked here in order to not accidentally clear them if
       * the bits are high when ixgbe_msix_other is called. There is a race
       * condition otherwise which results in possible performance loss
       * especially if the ixgbe_msix_other interrupt is triggering
       * consistently (as it would when PPS is turned on for the X540 device)
       */
      eicr &= 0xFFFF0000;

      IXGBE_WRITE_REG(hw, IXGBE_EICR, eicr);

...

      （略）

...


      if (unlikely(eicr & IXGBE_EICR_TIMESYNC))
          ixgbe_ptp_check_pps_event(adapter);

      /* re-enable the original interrupt state, no lsc, no queues */
      if (!test_bit(__IXGBE_DOWN, &adapter->state))
          ixgbe_irq_enable(adapter, false, false);

      return IRQ_HANDLED;
  }

やりました，ついに見つけました。3185，3186 行目，EICR というレジスタを確認して，ixgbe_ptp_check_pps_event(adapter) を呼び出しています。IXGBE_EICR_TIMESYNC というのは，レジスタ EIRC と論理積でテストをしているためレジスタの何らかのフラグではないかと考えられます。 X550 のデータシートの EICR レジスタのところ[4 sec. 8.2.2.6.1]を確認すると，割り込み原因が書き込まれるレジスタであることがわかります。どうやら 24-bit 目が TIMESYNC レジスタのようで，NIC に時刻同期を要求する割り込みが来るとこのフラグが立つようです。

さて，この ixgbe_ptp_check_pps_event() を探してみると，ixgbe_main.c にはありません。ついにこのファイルから離れ他のファイルを探してみると，ixgbe_ptp.cの 559 行目に見つかります。

/**
 * ixgbe_ptp_check_pps_event
 * @adapter: the private adapter structure
 *
 * This function is called by the interrupt routine when checking for
 * interrupts. It will check and handle a pps event.
 */
void ixgbe_ptp_check_pps_event(struct ixgbe_adapter *adapter)
{
    struct ixgbe_hw *hw = &adapter->hw;
    struct ptp_clock_event event;

    event.type = PTP_CLOCK_PPS;

    /* this check is necessary in case the interrupt was enabled via some
     * alternative means (ex. debug_fs). Better to check here than
     * everywhere that calls this function.
     */
    if (!adapter->ptp_clock)
        return;

    switch (hw->mac.type) {
    case ixgbe_mac_X540:
        ptp_clock_event(adapter->ptp_clock, &event);
        break;
    default:
        break;
    }
}

NIC のドライバなのでちょっと混乱しそうになるのですが，ここで言う pps とは packet per second ではなく，pulse per second signal です。1 秒あたりのパルス数を表示する単位，pulses per second とも違います。キッカリ 1 秒ごとにパルスを発するような信号のことを言い，この pulse per second signal のための Unix-like OS の API が RFC に策定されていたりします[7]。

この関数，ptp_clock_event() を呼び出していますが，X540 の場合のみ対応しているようです。X550 は対応していないのかしら。ここで終わってしまうのもなんなので，この先の処理も追ってみます。

ここからは ixgbe のコードを一気に離れ，ptp のコードに入ります。drivers/ptp/ptp_clock.c の 325 行目を見てみましょう。

void ptp_clock_event(struct ptp_clock *ptp, struct ptp_clock_event *event)
  {
      struct pps_event_time evt;

      switch (event->type) {

      case PTP_CLOCK_ALARM:
          break;

      case PTP_CLOCK_EXTTS:
          enqueue_external_timestamp(&ptp->tsevq, event);
          wake_up_interruptible(&ptp->tsev_wq);
          break;

      case PTP_CLOCK_PPS:
          pps_get_ts(&evt);
          pps_event(ptp->pps_source, &evt, PTP_PPS_EVENT, NULL);
          break;

      case PTP_CLOCK_PPSUSR:
          pps_event(ptp->pps_source, &event->pps_times,
                PTP_PPS_EVENT, NULL);
          break;
      }
  }
  EXPORT_SYMBOL(ptp_clock_event);

ptp_clock_event() は PTP_CLOCK_PPS というイベントで呼び出されていました。そこでみてみると，pps_event() という API が呼び出されています。この関数の説明は Documentations/pps/pps.txt にも載ってまして，割り込みハンドラのような pps 信号へのイベントはこれを使い登録するそうです。この関数の定義は drivers/pps/kapi.c の 172 行目にあり，

/* pps_event - register a PPS event into the system
 * @pps: the PPS device
 * @ts: the event timestamp
 * @event: the event type
 * @data: userdef pointer
 *
 * This function is used by each PPS client in order to register a new
 * PPS event into the system (it's usually called inside an IRQ handler).
 *
 * If an echo function is associated with the PPS device it will be called
 * as:
 *  pps->info.echo(pps, event, data);
 */
void pps_event(struct pps_device *pps, struct pps_event_time *ts, int event,
          void *data)
{
    unsigned long flags;
    int captured = 0;
    struct pps_ktime ts_real = { .sec = 0, .nsec = 0, .flags = 0 };

...

      （略）

...


    pps_kc_event(pps, ts, event);

    /* Wake up if captured something */
    if (captured) {
        pps->last_ev++;
        wake_up_interruptible_all(&pps->queue);

        kill_fasync(&pps->async_queue, SIGIO, POLL_IN);
    }

    spin_unlock_irqrestore(&pps->lock, flags);
}
EXPORT_SYMBOL(pps_event);

さらに pps_kc_event() が呼ばれています。この関数の定義は drivers/pps/kc.c の 112 行目であり，pps 信号のイベントに対してただ hardpps() を呼び出すだけのようです。

/* pps_kc_event - call hardpps() on PPS event
 * @pps: the PPS source
 * @ts: PPS event timestamp
 * @event: PPS event edge
 *
 * This function calls hardpps() when an event from bound PPS source occurs.
 */
void pps_kc_event(struct pps_device *pps, struct pps_event_time *ts,
         int event)
{
     unsigned long flags;

     /* Pass some events to kernel consumer if activated */
     spin_lock_irqsave(&pps_kc_hardpps_lock, flags);
     if (pps == pps_kc_hardpps_dev && event & pps_kc_hardpps_mode)
          hardpps(&ts->ts_real, &ts->ts_raw);
     spin_unlock_irqrestore(&pps_kc_hardpps_lock, flags);
}

そろそろ脳内の呼び出しスタックも深くなりすぎていい加減うんざりしてきたところだと思います。hardpps() のコードともなるともはやドライバーのソースですらありません。kernel/time/timekeeping.c 2347 行目，

#ifdef CONFIG_NTP_PPS
/**
 * hardpps() - Accessor function to NTP __hardpps function
 */
void hardpps(const struct timespec64 *phase_ts, const struct timespec64 *raw_ts)
{
    unsigned long flags;

    raw_spin_lock_irqsave(&timekeeper_lock, flags);
    write_seqcount_begin(&tk_core.seq);

        __hardpps(phase_ts, raw_ts);

    write_seqcount_end(&tk_core.seq);
    raw_spin_unlock_irqrestore(&timekeeper_lock, flags);
}
EXPORT_SYMBOL(hardpps);
#endif /* CONFIG_NTP_PPS */

これもまたロックなどをしていますが関数を呼び出しているのが主な処理であり，__hardpps()という NTP の処理のための内部関数を呼んでいます。 kernel/time/ntp.c の 973 行目，

/*
 * __hardpps() - discipline CPU clock oscillator to external PPS signal
 *
 * This routine is called at each PPS signal arrival in order to
 * discipline the CPU clock oscillator to the PPS signal. It takes two
 * parameters: REALTIME and MONOTONIC_RAW clock timestamps. The former
 * is used to correct clock phase error and the latter is used to
 * correct the frequency.
 *
 * This code is based on David Mills's reference nanokernel
 * implementation. It was mostly rewritten but keeps the same idea.
 */
void __hardpps(const struct timespec64 *phase_ts, const struct timespec64 *raw_ts)
{
    struct pps_normtime pts_norm, freq_norm;

    pts_norm = pps_normalize_ts(*phase_ts);
        
        ...

コメントによるとどうやら，hardpps() というのはまたもや出てきた NTP の著者の David L. Mills 博士の成果である nanokernel の実装が初出のものだそうです。 nanokernel というのを調べてみると，アメリカの航海学会で開催されている Precise Time and Time Interval (PTTI) Meeting（正確な時間と時間間隔の会合）のうち第 32 回目のときに報告された論文が元のようですね[8]。なんか意外な学会ですが，PTTI 2000 の URL は U.S. Navy のドメインでホストされていたのでなんか納得。海軍の作戦行動とかシステムはやっぱり時刻同期も重要なのでしょう。

この論文を読んでも良いのですが，どうやらhardpps()のアルゴリズムについては NTP.org にある解説のほうが要約されていてわかりやすそうです[9]。システムの時計での pps と外部信号（今回は PTP による pps ですね）を使って，システムの時計のオフセットのズレや周期のズレといったものを最小化しつつ pps に同期するようです。

次回予告

お気づきかもしれませんが，途中で割り込みハンドラ登録関数であるところの request_irq() の処理についてすっ飛ばしました。なので，たとえば NIC に PTP から時刻同期の信号が入り OS に割り込みが MSI-X を通じて飛んだとして，先程まで読んできた hardpps() を呼びだすような割り込みベクタ ixgbe_msix_other がどのように呼び出されるかはまだわかっていません。この割り込みの呼び出しにはどのような処理がありどのくらいオーバーヘッドが見込まれるでしょうか。次回をお楽しみください。

宣伝

100 Gbps のネットワーク，数 GB/s の速度の I/O を持つストレージ，ピコ秒単位で刻まれる CPU クロック，さらに不揮発性メモリの登場によりさらに速度やレイテンシといったものを積み，ナノ秒やピコ秒の世界が当たり前になりつつある計算機の世界ですが，これらのハードウェアとそれを司るソフトウェアを新たに実装したとしても，その性能の計測は正確でないと意味がありません。そこで，ナノ秒レベルでの時刻同期や時刻計測の手法も重要になってきます。

そこで，このような高精度な時刻について関心があるまたは，それを使って研究をしたり卒論や修論を書きたいという学生はぜひ，IIJ Innovation Institute（IIJ 技術研究所）でアルバイトをしてみませんか。アルバイトとして研究を進めることができ，そこそこのお給料を貰えたりネットワークや低レイヤ，データセンターのプロと議論できたりします。勤務地は飯田橋です。

また，時刻同期だけではなく IIJ-II では 100 GbE のネットワークを実機を用いて実験できたり，libraryOS やクラウドといった部分での研究・実験もやってたりします。学生のアルバイトは常に募集しているので，分散システムやクラウド，OS，ネットワークなどに興味のある関東近辺の学生は是非声をかけてください。

気になった方は @kotatsu_mi か私の上司である @yojiro まで DM などで気軽にご相談ください。

参考文献

[1] IEEE，“IEEE 1588^TM Standard for A Precision Clock Synchronization Protocol for Networked Measurement and Control Systems,” URL: https://www.nist.gov/el/intelligent-systems-division-73500/ieee-1588.
[2] D. L. Mills, “The Fuzzball,” in Proc. of Symposium Proceedings on Communications Architectures and Protocols, Aug. 1988, pp. 115-122. URL: https://www.eecis.udel.edu/~mills/database/papers/fuzz.pdf.
[3] D. L. Mills, “Internet Time Synchronization: the Network Time Protocol,” IETF, Oct. 1989, URL: https://tools.ietf.org/pdf/rfc1129.pdf.
[4] Intel, “Intel®︎ Ethernet Controller X550 Datasheet,” URL: https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/ethernet-x550-datasheet.pdf.
[5] Intel, “Intel® 64 and IA-32 architectures software developer's manual volume 3A: System programming guide, part 1,” URL: https://software.intel.com/en-us/articles/intel-sdm.
[6] PCI-SIG, “PCI Local Bus Specification Revision 3.0,” URL: https://www.xilinx.com/Attachment/PCI_SPEV_V3_0.pdf.
[7] J. Mogul, D. Mills, J. Brittenson, J. Stone and U. Windl “Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0,” IETF, Mar. 2000, URL: https://tools.ietf.org/html/rfc2783.
[8] D. L. Mills and P.-H. Kamp, “THE NANOKERNEL,” in Proc. of 32^nd Annual Precise Time and Time Interval Meeting, Nov. 2000, pp. 423-430. URL: https://www.eecis.udel.edu/~mills/database/papers/nanokernel.pdf.
[9] NTP.org, “5.2 The Kernel Dicipline,” URL: http://www.ntp.org/ntpfaq/NTP-s-algo-kernel.htm#Q-ALGO-KERNEL-HARDPPS.

コードカヴァレッジ計測

2020-11-11T09:46:00.004+09:00

コードカヴァレッジとは

あるプログラムコードについて実行した際に、実際にコード中の命令を何割実行したかを数値に表したものを言う。

計測手法

方法は様々である。たとえば、Linux kernel の fuzzer である Google の syzkaller を用いれば、ユーザーアプリケーションへの入力を自動で変化させつつコードカヴァレッジを確認させてくれる。また、Linux kernel のコンフィグ自体にもカヴァレッジについてのコンフィグが存在する。これは masami256 さんのブログなどが詳しい。

今回は gcc に組込みの手法でカヴァレッジテストを実行する手法についてメモをする

`gcov`

gcov がカヴァレッジ情報を .gcov という拡張子でダンプすることでカヴァレッジを確認できる。このコマンドは gcc に附属している。

使い方を見ていく

このようなソースコードを用意し、次のようにコンパイルする。

$ gcc -fprofile-arcs -ftest-coverage -o cov_test cov_test.c

すると次のようなファイルが用意されるはずだ。

$ ls
cov_test cov_test.c cov_test.gcno

これでカヴァレッジテストの準備は完了した。では、実際にカヴァレッジテストを行なってみよう。まずは、何も引数を与えずコンパイルしたコードを実行する。

$ ./cov_test
./cov_test: you need to pass arguments at least 1
$ ls
cov_test  cov_test.c  cov_test.gcda  cov_test.gcno

.gcno に加えて .gcda が追加されている。このファイルがカヴァレッジテストの結果を格納している。ここで、gcov コマンドを用いてみよう。

$ gcov cov_test.gcda
File 'cov_test.c'
Lines executed:38.89% of 18
Creating 'cov_test.c.gcov'

cov_test.c というコード全体が 18 行で、そのうち 38.89% が実行されたということを物語っている。また、ここで新たに出力されたファイルの中身を見てみよう。

$ cat cov_test.c.gcov
        -:    0:Source:cov_test.c
        -:    0:Graph:cov_test.gcno
        -:    0:Data:cov_test.gcda
        -:    0:Runs:1
        -:    0:Programs:1
        -:    1:#include <stdio.h>
        -:    2:#include <stdlib.h>
        -:    3:
        1:    4:void usage(char *cmd)
        -:    5:{
        1:    6:    fprintf(stderr, "%s: you need to pass arguments at least 1\n", cmd);
        1:    7:    return;
        -:    8:}
        -:    9:
        1:   10:int main(int argc, char **argv)
        -:   11:{
        1:   12:    if (argc < 2) {
        1:   13:        usage(argv[0]);
        1:   14:        exit(EXIT_FAILURE);
        -:   15:    }
        -:   16:
    #####:   17:    switch (argc) {
    #####:   18:        case 2:
    #####:   19:            printf("you passed 1 argument\n");
    #####:   20:            break;
    #####:   21:        case 3:
    #####:   22:            printf("you passed 2 arguments\n");
    #####:   23:            break;
    #####:   24:        default:
    #####:   25:            printf("you passed more than 3 arguments\n");
    #####:   26:            break;
        -:   27:    }
    #####:   28:    return EXIT_SUCCESS;
        -:   29:}

見てのとおり、コード全体のうち空行やプリプロセッサの行、ブラケットのみの行などを除いた行のうち、実行された 1 でマークされており、実行されなかった行は ##### でマークされている。この両者の合計は 18 行であり、そのうち 1 でマークした行は 7 行、7/18 = 0.38.. というわけである。続けて、引数をいくつか与えてみる。

$ ./cov_test 1
you passed 1 argument
$ gcov cov_test.c.gcov
File 'cov_test.c'
Lines executed:66.67% of 18
Creating 'cov_test.c.gcov'

$ ./cov_test 1 2
you passed 2 arguments
$ gcov cov_test.c.gcov
File 'cov_test.c'
Lines executed:83.33% of 18
Creating 'cov_test.c.gcov'

どうだろうか。実行する度に引数を変えているため、当然コードパスも異なる。そして、そのぶんカヴァレッジ率が積算されている。

$ cat cov_test.c.gcov
        -:    0:Source:cov_test.c
        -:    0:Graph:cov_test.gcno
        -:    0:Data:cov_test.gcda
        -:    0:Runs:3
        -:    0:Programs:1
        -:    1:#include <stdio.h>
        -:    2:#include <stdlib.h>
        -:    3:
        1:    4:void usage(char *cmd)
        -:    5:{
        1:    6:    fprintf(stderr, "%s: you need to pass arguments at least 1\n", cmd);
        1:    7:    return;
        -:    8:}
        -:    9:
        3:   10:int main(int argc, char **argv)
        -:   11:{
        3:   12:    if (argc < 2) {
        1:   13:        usage(argv[0]);
        1:   14:        exit(EXIT_FAILURE);
        -:   15:    }
        -:   16:
        2:   17:    switch (argc) {
        1:   18:        case 2:
        1:   19:            printf("you passed 1 argument\n");
        1:   20:            break;
        1:   21:        case 3:
        1:   22:            printf("you passed 2 arguments\n");
        1:   23:            break;
    #####:   24:        default:
    #####:   25:            printf("you passed more than 3 arguments\n");
    #####:   26:            break;
        -:   27:    }
        2:   28:    return EXIT_SUCCESS;
        -:   29:}

.gcov を確認してみると、実行しなかった行を示す ##### のマークは減っている。その変わり、新たに実行された行は 1 がマークされており、また、何度も実行された行はその回数に合わせ 2 や 3 がマークされている。

$ ./cov_test 1 2 3
you passed more than 3 arguments
$ gcov cov_test.gcda
File 'cov_test.c'
Lines executed:100.00% of 18
Creating 'cov_test.c.gcov'

cat cov_test.c.gcov
        -:    0:Source:cov_test.c
        -:    0:Graph:cov_test.gcno
        -:    0:Data:cov_test.gcda
        -:    0:Runs:4
        -:    0:Programs:1
        -:    1:#include <stdio.h>
        -:    2:#include <stdlib.h>
        -:    3:
        1:    4:void usage(char *cmd)
        -:    5:{
        1:    6:    fprintf(stderr, "%s: you need to pass arguments at least 1\n", cmd);
        1:    7:    return;
        -:    8:}
        -:    9:
        4:   10:int main(int argc, char **argv)
        -:   11:{
        4:   12:    if (argc < 2) {
        1:   13:        usage(argv[0]);
        1:   14:        exit(EXIT_FAILURE);
        -:   15:    }
        -:   16:
        3:   17:    switch (argc) {
        1:   18:        case 2:
        1:   19:            printf("you passed 1 argument\n");
        1:   20:            break;
        1:   21:        case 3:
        1:   22:            printf("you passed 2 arguments\n");
        1:   23:            break;
        1:   24:        default:
        1:   25:            printf("you passed more than 3 arguments\n");
        1:   26:            break;
        -:   27:    }
        3:   28:    return EXIT_SUCCESS;
        -:   29:}

そしてついには、全てのコードパスを実行することに成功し、100% が表示され、.gcov ファイルにおいても全ての行に数字がマークされている。また、4 回の実行のうち、どの行が必ず実行され、どの行が場合によって実行されないかもマークされた数字によってある程度把握可能になる。

`lcov, genhtml`

これは別個インストールが必要である。インストール後、.gcda があるディレクトリで次のように用いる。

$ lcov -c -d. -o cov.info
Capturing coverage data from .
Found gcov version: 7.3.1
Scanning . for .gcda files ...
Found 1 data files in .
Processing cov_test.gcda
TN:
SF:/home/orumin/cov/cov_test.c
FN:4,usage
FN:10,main
FNDA:1,usage
FNDA:4,main
FNF:2
FNH:2
DA:4,1
DA:6,1
DA:7,1
DA:10,4
DA:12,4
DA:13,1
DA:14,1
DA:17,3
DA:18,1
DA:19,1
DA:20,1
DA:21,1
DA:22,1
DA:23,1
DA:24,1
DA:25,1
DA:26,1
DA:28,3
LF:18
LH:18
end_of_record
Finished .info-file creation
$ genhtml cov.info
Reading data file cov.info
Found 1 entries.
Found common filename prefix "/home/orumin"
Writing .css and .png files.
Generating output.
Processing file cov/cov_test.c
Writing directory view page.
Overall coverage rate:
  lines......: 100.0% (18 of 18 lines)
  functions..: 100.0% (2 of 2 functions)

すると、次のようにファイルが出力される

$ ls
amber.png  cov  cov.info  cov_test  cov_test.c  cov_test.gcda  cov_test.gcno  emerald.png  gcov.css  glass.png  index.html  index-sort-f.html  index-sort-l.html  ruby.png  snow.png  updown.png

すなわち、gcov コマンドで plain text を出力する代わりに HTML でグラフィカルにカヴァレッジテストの結果を出力できるというわけである。

静電容量Helix (EC Helix) NiZ スイッチ ver. ビルドログ (β2)

2020-10-12T20:28:00.016+09:00

前書き

兼ねてより自作キーボードに興味はあったのですが静電容量無接点式スイッチ（東プレスイッチ）の分割が実現できそうになるまでやらないと公言しておりました。以前より Custom Topre Guide など指針になるものがちらほら出てたようなのですが，今年の春先ごろ銀鮭（@sorojake）さんが Booth で『真の静電容量キーボードを作る本』というものを出しているのを見掛け，どうやら PCB 設計勉強したり発注しなきゃいけないかなあと思っていたのですが，ありがたいことに Helix ベースのキットを出して貰えるということで，今回β2 版のテスターとして購入・製作しました。

長くなりましたが，次から実際に製作した過程とそのメモです。

実は初自作キーボード。

disclaimer

β2 版のビルドログなので正式版とは異なる可能性があります。ご了承ください。

ビルドログ

道具・機材

静電容量Helix ラバードームタイプ(β2)キット
NiZ のハウジングと軸×100
東プレ OEM キーボードのジャンクから剥いだラバードームと円錐型スプリング

Hitachi 2050 という 80 年代ぐらいのワークステーション付属のものらしい。
いまならビットトレードワンさんが製作しているものを買うほうが簡単だし安いはず。遊舎工房にも置いてあった。これを買う場合はハウジングや軸もセットだから NiZ から何か買う必要はなし。

キーキャップ ENJOYPBT ABS Doubleshot Dolch

遊舎工房実店舗で購入したけど，KBDFans で自分で買うほうが安いかも（ただしその場合届くまでのタイムラグがある）

Pro Micro×2，OLED×2，LED (SK6812mini)×54，M2 スペーサー 8mm（OLED 保護アクリル用）

いずれも遊舎工房の実店舗にて購入

アクリルプレート Helix 向け 2mm 厚（押し出し・クリア）

遊舎工房オンライン発注サービス利用

ジャンパ用銅線，絶縁テープ

うっかり買うの忘れてたので製作直前で適当にホームセンターで購入

はんだこて先 (HAKKO T18-S9)，フラックス (HAKKO FS-200)，フラックスクリーナー（Sunhayato FL-L15)，高密度集積基板用糸はんだ (goot SF-B1004, 0.4φ)

いずれも秋葉原の千石電商にて購入
こて先は遊舎工房で聞いたおすすめなのだけれども，SOP のチップ実装には D 型ではなく K 型のほうがよかったのでは？と後で友人に指摘された。

ソルダーアシスト (goot SA-10)

これも千石で購入。チップ押さえとかめっちゃ役立った。後述。でも今考えるとヒートクリップとかでも良かったね。

はんだこて (HAKKO FX-600)，はんだこて台 (HAKKO 633)，はんだ吸い取り線 (HOZAN No.3793)，デジタルマルチメーター (SANWA CD771)

どれも以前から所有して利用していたもの。新しく買うならたぶん吸い取り線はもっと細いやつとか買うほうがいいです。

ドキュメント類

オリジナル Helix の公式ビルドログ
オリジナル Helix のビルドログで参考にしたログ（id:hano_tea 氏によるもの）
銀鮭さんの EC Helix 設計者によるビルドログ

製作

注意点

チップ部品や LED の実装は取り立てて難しくないし，もし不安ならオリジナル Helix のビルドログを再確認すれば良いけれども，ふたつほど SOP パッケージのチップ（ピンのピッチが 1.27mm）があって，とくにマルチプレクサが一片あたり 8-pin あるので失敗しやすい。一度だめにしていい基板と SOP のチップを用意して，素振りしておくと良いと思った。たぶん一度練習すればじゅうぶん。

はじめ

まず部品の種類や点数を確認しましょう。でないと私みたいに動作確認のために Pro Micro を開封してから「あれ，コンスルーが入ってない？」とか言って秋葉原に駆け込むハメになります。確認だいじ。

Pro Micro 実装予定場所のジャンパ・絶縁（左手側のみ）

基本的に銀鮭さんのビルドログ通り。ジャンパさせるのは左手側かつ表側です。

スルーホールに銅線を 13 本すべて通してから，裏側からはんだ付けして，余った足はニッパーで切断しました。

あとビルドログにはないですが，OLED 使う予定の人は絶縁テープ貼る前に Pro Micro 実装予定場所の下側のランドもジャンパさせてしまったほうがいいです。私はうっかり完成してからジャンパしてないことに気付きました。

本家 Helix と違って OLED 実装のためにジャンパさせる場所に文字のシルクはありませんが，本家と同じ場所を同じやり方でオッケー。

表面実装

PCB をひっくりかえして，実装していきます。本家と違ってキーひとつごとにパーツを実装する必要はなく，Pro Micro 実装予定場所の裏側にチップ部品が密集しています。

さきに SOP パッケージチップ 2 つ（マルチプレクサ，OP アンプ）を実装したほうがこて先を動かす空間が確保しやくて失敗したときのリカバリーもしやすいと思います。

SOP

SOP を実装するときは，フラックスを PCB にたっぷり塗っておいて，ランドひとつだけ予備はんだをしておき，ピンセットでチップを持ったらまず足一本だけ予備はんだをくっつけておいて，次に対角線の足もはんだで固定します。このときソルダーアシストセットに含まれていたチップ押さえがおおいに役立ちました。

次に，一辺にフラックスを塗ってから，こて先の直線になっている部分をランドと端子の境界にあて，はんだを流しながらこて先もこの直線部分をチップの辺と平行に滑らせていきます。複数の足にまとめてはんだ流すかんじです。

このときわりと大きな確率でチップのピンとピンの間がはんだブリッジしてしまいますが，多少はんだが多めに盛ってあるほうがかえってはんだ吸い取り線で吸い取りやすいので，それで綺麗にしてしまいます。はんだを吸い取るときもフラックスを付けておけば，たぶんいい感じに必要量だけ残るはず。

一度失敗してから，こういう動画とかサイトとか眺めてイメージトレーニングしてからはんだ付けに臨みました。これは SOP より一際ピンのピッチが狭く (0.5 mm) さらにピンが四辺から出ている QFP ですが。

吸い取るときは私はこて先温度を 320～370 のダイヤルにしていました。利用した吸い取り線が 3.8mm だったのもあって多少温度を大きめにしないとそもそも吸い取れませんでした。このぐらいの温度でもチップはたぶん大丈夫です。

このとき，極めて少量だけがうっかりピンの根本とかでブリッジしてしまったなどの場合，へたに掻き出したり吸い取ろうとしたりせずいちどはんだを盛ってしまったほうが私はラクに感じました。

私の場合は最初それに気付かず，また，吸い取り線に対する温度が低すぎるのにも気付かなかったため，ニッパーでピンを切ってから余計なはんだを吸い取ってリカバリーしよとして，かえって取り外したチップとともにランドとパターンが剥離してしまったため PCB のお代わりを銀鮭さんから送ってもらうという失態をしました……。

（ひとつダメにしたのはマルチプレクサでしたが，こっちは予備がキットにひとつ入っており，なんとかなりました。しかし既に実装していた OP アンプのほうは余りパーツもなく，また，SOP を取り外せる自信もなく，これまた銀鮭さんに OP アンプをひとつ都合してもらいました。大変感謝です！）

ルーペは持っていませんでしたが，幸いなことにチップ抵抗表面の印刷や SOP のピンとピンの間ブリッジしてないかとかはギリギリ肉眼で視認できたためなんとかなりました。

その他チップ部品

私の場合の実装順ですが，まず 200 Ω 抵抗を全て実装し，次にマルチプレクサのすぐ下側のチップコンデンサ，10k Ω 抵抗，そしてトランジスタ，トランジスタ脇の 10k Ω 抵抗，その下側の 1k Ω 抵抗，51k Ω 抵抗，OP アンプ脇の 10k Ω 抵抗，そして最後に 100k Ω 抵抗を全て実装，という手順で実装しました。このへんの順番はどうでもいいのですが，チップとチップの間隔が狭いのでこて先を動かしやすい順番を気をつけると良さそうです。

LED

LED を実装したい人はここで実装するとよいでしょう。すでに LED 実装の注意点は本家 Helix のビルドログで語られ尽くしているのであまり多くは書きません。私はこての温度ダイヤルを 270 度にし，こて先に溶かしたはんだをたっぷり盛ったうえで，PCB と LED にフラックスをたっぷり塗り，左手はソルダーアシストセットのチップ押さえで LED 動かないよう上からしっかり抑え，右手は PCB と LED のそれぞれのランドを始点・終点にした直線を引くつもりですっとコテを動かしてピンをひとつ固定してから，あとは糸はんだ片手に残りのピンを付けていきました。

注意点

ここまでの実装を終えたらたぶん焦げたフラックスで PCB 裏面はやや茶色くなっている場所がちらほらあったり，べとべとしたりしていると思いますが，ここでフラックスクリーナーで綺麗にすると茶色いのが消えてべとべとが取れていいカンジです。また，フラックスを落とさずそのままにすると基板が腐食する可能性もあるそうで……。

表側部品

PCB をまたひっくりかえして，リセットスイッチ，TRRS ジャック，OLED のためのピンソケットを実装します。部品の足をスルーホールに通したらはんだは裏側から。

ProMicro/OLED

どちらもコンスルーやピンヘッダを PCB ではなくそれぞれ ProMicro 側と OLED 側にはんだ付けする必要があります。ProMicro にはコンスルー以外に普通のピンヘッダも同梱されており，また，コンスルーには向きがあるため，本家 Helix の公式ビルドログを見ながら注意深く実装しましょう。

ファームウェアビルド

ビルドの前に AVR アーキテクチャ向けの gcc, binutils, libc をインストールしておかなければなりません。

ただしこれを Alpine Linux でやったらビルドの最後の最後でリンカーがリンカスクリプト (avr5.xn) を発見できずにコケました。実際はファイル自体はパッケージからインストールされていたので，パッケージのバグだと思われますが，誰も Alpine なんかで AVR 向けのコンパイルをしたりしないんですかね。普通の Hello, World! を gcc -mmcu=avr5 でコンパイルしてもコケました。まあメンテナンスされていないだけだとは思いますが，素直に Ubuntu とか使っておきましょう。

ちなみにこれは Gentoo では解決されているらしい https://bugs.gentoo.org/530786

気を取り直して以下が具体的なビルド手順

git clone https://github.com/orumin/qmk_firmware
cd qmk_firmware
git submodule update --init --recursive
qmk compile -kb ec_helix -km default

上記ではなぜか脱落してる submodule を手動で追加していますが，将来的には git submodule add ... の三行ぶんはやらなくて良くなるんじゃないかな。~~修正作って pull-request を送ろうと思っているので。~~ force push とか必要そうかつかなり巨大な差分になる修正だったので pull-request を出すのは諦めましたが，銀鮭さんに問題解決の対応をして頂きました。現在は git submodule add .. とある 3 行ぶんのコマンドは不要です。

もともと ginjake さんの repository を参照したビルド例を記載していましたが、現在 QMK 0.22 に対応した版を私の repository で作成したので以後 firmware 関連の記載修正しました (2023-11-19)

現在 qmk_firmware/keyboards/ec_helix/rule.mk の OLED_DRIVER_ENABlE がもし yes になっているのならば，完成して動作確認終えるまでは no にしておいたほうがキー入力の確認とりやすいと思います。ただし OLED の動作確認をさきにしておきたい場合はそれを行なってから書き換えると吉。

あとキーレイアウト変えたければ

qmk new-keymap -kb ec_helix
cd keyboards/ec_helix/keymaps/<your git user name>

を実行したのち、keymap.c を書き換えます。ビルドの最後の手順も qmk comile -kb ec_helix -km default から qmk -kb ec_helix -km orumin のように作ったキーレイアウトの名前に書き換えて実施しましょう。

作ったファームウェアファイルは以下のように書込みます。このとき avrdude とやらが必要なのでこれもパッケージから入れておいてください。

avrdude -c avr109 -p m32u4 -P /dev/ttyUSB001 -U flash:w:ec_helix_default.hex

このなかの /dev/ttyUSB001 のところは環境依存です。数字の部分が環境によって違うだけでなく，たとえば Windows だと COM1 とか COM7 とかの COM Port になります。

作成したファームウェアを書き込むときは、

qmk flash -kb ec_helix -km default

のようにコマンドを実行した後、基板上の ProMicro の近くにあるタクトスイッチを押して DFU mode に切り替えます。ここで、両手ぶんそれぞれに書き込むことを忘れずに。

ただし WSL 上の場合、実際 Windows の COMn としてシリアルポートが接続されるのに反して WSL 内の Linux が /dev/ttyUSB0 などに新しいシリアルデバイスが接続されることを期待して待ち受けてしまうため、うまいくいきません。この場合は次のようにすると良いでしょう。

# qmk_firmware ディレクトリに居ると仮定します
cd ../
git clone https://github.com/qmk/qmk_toolbox
cp qmk_firmware/ec_helix_default.hex .
qmk_toolbox/windows/QMK\ Toolbox/avrdude.exe -C qmk_toolbox/common/avrdude.conf -c avr109 -p m32u4 -P COM10 -U flash:w:ec_helix_default.hex

こちら、コマンドを忘れがちなのと、コマンド実行した後に新しく接続されてくるシリアルデバイスを検知してから実際に書込みモードに移行するような挙動であってほしいので、こういうヘルパースクリプトを用意してみました。 https://gist.github.com/orumin/26e4840fd8aa23cbaac9fdf11e3df01f

動作確認

これは完成後動かないキーを修正してるとき気付いたのですが，この時点で LED だけじゃなくキーの動作確認もしてしまったほうがいいです。やりかたは，ボトムプレートの上に M5 スペーサー（黒いわっかです）をのせてその上にファームウェア焼き込み済み ProMicro を搭載した PCB を載せます。そして，キーひとつぶんだけに切られたラバードームとスプリングひとつ，そしてハウジングと軸もひとつずつ用意しましょう。最後に，PCB 上のテストしたいキーの位置の円のシルクがあるところに，スプリング，ラバードーム，軸，ハウジングの順番でのっけて，これでテストします。別のキーを試したければ，このスイッチ一式をそのまま別のキーの位置に滑らすだけです。

クソ雑動作確認 pic.twitter.com/ezGeY0Q2OO
— まちカドおるみん (@kotatsu_mi) October 11, 2020

注意点としては，この方法だとノイズが防げないため，確実と言っていいほど入力が暴走します（チャタリング）。メモ帳を開いてカーソルを合わせておくなど，不意のキー入力でも困らないようにしておいてください。

またこの方法ではあくまでキーがまったく読みとれない不具合がないかどうかだけ確認するなど割り切った確認として，実際にチャタリングが起きないかなどは完成後にあらためて確認しましょう。

ところで静電容量無接点方式でバネの具合やノイズなどで静電容量が微妙に閾値を超えて入力状態と誤判定される，のはチャタリングと表現して良いのでしょうか。正しい用語ではないかもしれない……。

スイッチとケース（アクリルプレート）の実装

もうここまで来るとはんだごても要らなくなりあとはやるだけです。手順も銀鮭さんのビルドログ通り。

ポイントとしては，ハウジングはトッププレートに嵌めるんですが，このとき工作精度の都合上たまにゆるゆるなハウジングが居たりします。どうせ NiZ から買うと 100 個も届いて余るので，微妙そうなハウジングは除けて別のハウジング使うといいと思います。

また，ハウジングと軸をトッププレートの裏側に嵌めたところで，スムーズに軸が動くかテストすると良いかと思います。たまにハウジングのプレートに嵌めるためのツメが内側に曲がってて軸の動きを邪魔しているやつが居ました。

あと，これは一目で見ればわかるのであんま書かなくてもいいとは思いますが，NiZ のハウジングと軸は向きがあります。軸を嵌める向きがおかしいとユルユルになります。

この場合は後者は間違った向き。

一度完成してから PCB だけ取り出してはんだを直そうとかすると写真二枚目のようにハウジングや軸もバラバラに取れちゃいがちなので，気をつけましょう。万一 PCB の修正が要るなら腹括ってください。

あと，私が使ったラバードームのせいなのかキットの低頭ネジだとボトムプレート留めるのにやや長さが足りなかったので，元の Hitachi 2050 キーボードで内部の基板を留めるのに使われていたネジを流用しました。

完成

ということでおめでとうございます。ここまで来ればおおむね大丈夫でしょう。わたしはこの時点で右手側の特定列が入力できない（チップ抵抗がはんだ不足），OLED のジャンパ忘れなどで多少のやりなおしが発生しました。

一般にはんだは多すぎても少なすぎても，そして温めすぎてもダメですが，仕事ではなくホビーなので，動くこと優先で多少はんだが常に多めでも問題ないかと思います。動かないほうが怖いです。

余談ですがフルカラー RGB LED なものを持つのが初めてなもので，完成した最初の夜（昨夜ですね）寝ようと布団に入ったら天井がパーリナイな感じに綺麗に照らされてて笑ってしまいました。

おわりに

使ってみて

この記事は EC Helix (NiZ) で作成しています。おおむね問題はないんじゃないでしょうか。ただ，作った直後たまにスペースが効かなくなることがあったのですが，キーキャップを全て付けた時点で再発しなくなりました。ですが，OLED のジャンパ忘れを直し，この記事を書いていて，終盤になってからまたたまにスペースが効かなくなり，USB 抜き差しでリセットされるのか直るんですが，再発の間隔がどんどん狭くなっています。もしかしたら OLED はやめておいたほうがいいのかもしれません。仮に OLED は関係なかったとしたら，おそらく私の実装の問題でしょう。

追記：しばらく使ってたら OLED 付けていても安定するようになっていて、上記のような不具合は起きなくなっていました。

基本的にはかなりちゃんと動作するし，タイプ感も静電容量無接点式そのもので，とても良いです……。テンションガン上げ。

私が現在利用しているキーレイアウトは次のようなカンジです。 https://github.com/orumin/qmk_firmware/blob/ec_helix_orumin/keyboards/ec_helix/keymaps/orumin/keymap.c

最後の注意事項

キーレイアウトを変更したとき，左手側だけ書き換えても動くには動くんですが，ちゃんと両手どちらもファームウェア書き換えをしないと，右手側で取り零したり遅延が起きたりしました。両手どちらも書き換えたらちゃんと動作して，しかも入力はスムーズで最高です。

謝辞

こんな素敵なキットを作ってくれた上に壊れた PCB の都合や私の実装ミスによる不具合の解決のサポートまで色々してくださった銀鮭さん，大変ありがとうございました。

SuperH開発ストーリー

2020-10-10T20:14:00.002+09:00

かつてルネサスのサイトに掲載されていたが消滅してしまい，Internet Archive にもアーカイヴされていないがウェブ魚拓には残っていた。しかし話数とそのリンクを一覧するのが面倒なため以下にメモしておこうと思う。

こういうドキュメントは大切なので消さないで欲しいなあ……。

Line of Code (LoC) の計測

2020-08-13T20:08:00.001+09:00

LoCの計測で一番簡単だと思われるのは次のような方法である。

find ./src -type f -name '*.c' -o -name '*.h' | xargs wc -l

この例では ./src ディレクトリに含まれる C 言語のソースファイルとヘッダファイルについて全て wc(1) に食わせて行数を出力する，といったことを行なっている。

しかしこれでは，プロジェクトで利用する言語が増える度に find(1) のオプションを調整しなければならないし，コード内の空行やコメント行を全く考慮しない。

cloc

そこで，実は cloc という便利な LoC 計測ツールがあるらしい。https://github.com/AlDanial/cloc

このコマンドでは，単純にプロジェクトのディレクトリを引数として渡すと，どういう言語がどのくらい使われており，それぞれに含まれる空行とコメントはどのぐらいか，といったことを一覧表示してくれる。

しかし，私はLinux kernelにおける各サブシステムがコード全体のうちどのぐらいを占めているかを知りたかったため，次のように cloc を実行した。

cd /usr/src/linux/
for dir in $(find . -maxdepth 1 -type d ! \( -name '.*' -o -name 'Documentation' -o -name 'LICENSES' -o -name 'samples' -o -name 'scripts' -o -name 'tools' \)); do
    echo $dir
    cloc $dir
done > ~/linux_loc.txt

すると linux_loc.txt には次のような出力が得られる。

./arch
   16005 text files.
   15902 unique files.
    4299 files ignored.

github.com/AlDanial/cloc v 1.72  T=28.79 s (406.7 files/s, 90104.3 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                             4725         226114         234741        1106210
C/C++ Header                  5078          82383         114960         432840
Assembly                      1245          44995          98313         220827
make                           591           3298           3271          12514
Perl                             7           1187            959           7692
Bourne Shell                    55            398            621           2090
awk                              5             51             58            486
Python                           1              7             12             46
sed                              1              2              5              5
-------------------------------------------------------------------------------
SUM:                         11708         358435         452940        1782710
-------------------------------------------------------------------------------
./block
      94 text files.
      94 unique files.
       3 files ignored.
...

さて，欲しいのは各サブシステムのコードが全体に占める割合であるため，次のようにして各サブシステムのコード行数を表にしてしまう。

dirs=$(find . -maxdepth 1 -type d ! \( -name '.*' -o -name 'Documentation' -o -name 'LICENSES' -o -name 'samples' -o -name 'scripts' -o -name 'tools' \))
for i in $(grep SUM ~/linux_loc.txt | awk '{print $5}'); do
  echo -e "${dirs[$count]}\t$i"
  set count (expr $count + 1)
done | sort -r -n -k 2,2 > loc.txt

これで loc.txt には次のような出力が得られるはずである。

./drivers       13048806
./arch  1782710
./fs    967163
./sound 935637
./net   828886
./include       644501
./kernel        237713
./lib   131807
./mm    91805
./crypto        83988
./security      67041
./block 37711
./ipc   6689
./virt  5234
./init  3309
./usr   867
./certs 442

最後にこの TSV から集計と割合の計算を行う。そう，こういう時役立つのは awk 言語だ。

LOC_percentage=$(awk 'NR==FNR{sum=sum+$2;next}{percentage=$2/sum*100; print $0, "\t", percentage"%"}' loc.txt loc.txt)
LOC_total=$(awk '{sum+=$2} END {print "total\t",sum}' loc.txt)
echo "$LOC_percentage" > loc.txt
echo "$LOC_total" >> loc.txt

NR は行数だが，FNR はファイル単位の行数である。ここでは loc.txt を二回食わせているため，一度目では NR と FNR が一致するが，二度目では FNR はまた 1 からカウントアップされるが NR は一度目の数を引き継ぐため，一致しなくなる。そこで，一度目のループでのみ各ディレクトリのコード行数を足し合わせており，また，nextによってその次の {} で囲まれているコードは実行しない。

二度目のループでは二つ目の {} の中身のみを実行するため，一度目のループで取得した総和に対して各ディレクトリのコード行数の割合を計算する，といった具合になる。

最後に，Linux 5.8 に対してこれを行なって，得られた結果は次の通りとなる。

./drivers       13048806    69.1353%
./arch          1782710     9.44517%
./fs            967163      5.12423%
./sound         935637      4.9572%
./net           828886      4.39161%
./include       644501      3.4147%
./kernel        237713      1.25945%
./lib           131807      0.698341%
./mm            91805       0.486402%
./crypto        83988       0.444986%
./security      67041       0.355197%
./block         37711       0.199801%
./ipc           6689        0.0354397%
./virt          5234        0.0277308%
./init          3309        0.0175318%
./usr           867         0.00459355%
./certs         442         0.00234181%
total           l18874309

コードの実に 8 割が drivers/ と arch/ で占められ，次点に fs/，sound/，net/ ... と続く。

ちなみに同様のことを OSv に対して実行するとこのようになる。

./modules       421847   51.0683%
./bsd   251317   30.4241%
./musl  68332    8.27219%
./include       22400    2.71172%
./drivers       15663    1.89614%
./core  12595    1.52474%
./libc  11885    1.43878%
./fs    9164     1.10938%
./arch  9136     1.10599%
./      3166     0.383272%
./fastlz        526      0.0636769%
./compiler      14       0.00169482%
total   826045

最大の行数を誇るのは modules/ であるが，この部分は CLI や RESTful API server，Java VM のバルーニング実装に libz や ncurses，openssl といったものが並ぶ。通常の OS であればユーザーランドに置かれるものであり，OSv のビルドや実行にも必ずしも含まれると限らない。

bsd/ には主に FreeBSD 由来であるネットワークスタックと ZFS のコードを含み，カーネルとしては実質この部分が最大になる。次に musl-libc の移植コードである musl/ が続き，それから以降は OSv の独自実装が主となっていく。

また，./ となっているのは OSv の場合トップディレクトリにもいくつか重要なコードがあるためで，これは bootfs.S, dummy-shlib.cc, empty_bootfs.S, gen-ctype-data.cc, linux.cc, loader.cc, Makefile, runtime.cc の 8 つのファイルを集計したものとなる。

OSv は unikernel としては実装が大きいほうだが，それでも全体で 8 万行強であり，コア部分だけみるとたかだか 1 万行になっており，Linux に比べればカーネルの実装全体に目が通しやすい。

GitHub で一番古いコミットを辿る

2020-07-09T16:20:00.001+09:00

git clone したレポジトリを開いて git log でも眺めれば済む話なんですが，ちょっとコードが気になったとき Web ブラウザから閲覧してて最初のコミットはいつか，なんて気になったときにいちいち clone はしたくない。そういうときは次の手順で古いコミットが確認できます

GitHub の該当プロジェクトのページから「Insights → Network」を開く
「Shift + ←」あるいは「Shift + h」で一番古いコミットまでカーソルを移動
グラフ上の該当ノードをクリック

ただし，cVim のような Vim 互換のキーバインドをブラウザに導入する extension を入れてるとキーバインドがこっちに取られるので微妙に上手くいかないこともある。

追記

モバイル端末のひとはがんばってスクロールしてください（コミット歴のページで Older をタップしつづけるよりかはマシかもしれない）

IPv6 prefix と物理的な地理のカンケイ？

2020-07-03T07:51:00.001+09:00

NTT が構築してきたインフラ網として，公衆電話網，地域 IP 網，そして NGN がある。

たとえば公衆電話では電話番号がそのままルーティングに活用されており，電話交換機の仕組みと市外局番・市内局番の関係を調べると実に面白い。

また，地域 IP 網によってブロードバンドが提供されるようになっても，効率性や合理性の観点から，ISP によっては PTR で逆引きすることによってある程度はグローバルアドレスから県ぐらいまでの特定は可能なようだ。これは，昔のフレッツ網は県間通信が制限されていたため，特定の県内網にしか出口を持たない ISP が居たり，あるいは全国でサーヴィスを提供する ISP であっても県内網ごとにネットワークの出口を設けていたためである。

さて，では NGN ではどうだろう。

NGN では IPv6 が割り振られ，近年は IPoE の利用によって NGN から払い出されるアドレスで直接インターネットに接続できるようになった。

このインターネットに接続できる IPv6 アドレスは，IANA から RIR（地域インターネットレジストリ）の APINC，NIR（国別インターネットレジストリ）の JPNIC，そして LIR（ローカルインターネットレジストリ）である指定事業者に払い出され，そこから ISP に払い出されることになっている。IPoE の VNE は指定事業者である。 https://www.nic.ad.jp/ja/ip/member/cidr-block-list.txt

この VNE が管理する IPv6 プレフィックスは /30 である。このプレフィックスは NGN 内のサーバーに預けられており，払い出しや実際の割り振りの管理は NGN 内で実施されることになる。なので，ルーティングなどの合理性からいっても，地理的に近いユーザーは似たようなアドレスが払い出されるだろうということが想像できる。

実際に私の手元に降ってきている IPv6 プレフィックスはひかり電話契約有りなので /56 なので，そのような物理的な地理に基いたアドレス分けに利用できる長さは 56-30 = 26-bit ということになる。

さて，実際に IPv6 プレフィックスはどういう管理がなされているのか，実は判明しているらしい。

都道府県の識別は 2bit(東京)～8bit(島根、鳥取)の可変長。都道府県～収容局～エッジルーターまでで合計 13 bit。都道府県が短いところほど、その分収容局～エッジルーターにたくさん割り当てられる。エッジルーター内の回線はその後の 13 bit で識別できる。
【時代が追いついた】IPv6スレ ver11【にわか爆増】

実際に自分に払い出されている IPv6 プレフィックスを確認する，なるほどどうやらこれは合っているようにも思えるが，どうだろうか？

しかし自分の故郷である山陰が 8-bit の識別 ID になっているというのも，つまり人口の少なさ（＝加入者の少なさ）を反映しているのであろう，納得ではあるがとても悲しい気持ちになった。

BBIX の IPv4 over IPv6 技術は 4rd/SAM ではありません

2020-07-03T07:25:00.004+09:00

IPoE と IPv4 over IPv6

現在，インターネット接続性のある VNE が持っている IPv6 を，トンネリングせず NGN から直接払い出してもらう IPoE（ネイティブ方式）がにわかに普及している。当初 NGN に接続している VNE も BBIX，JPNE，MF の三社だけに制限されていたが，現在は NNTCom や Biglobe，ASAHInet など増加している

ところで，これら VNE がそれぞれ独自に提供している，IPv4 パケットを IPv6 上にカプセル化することによって IPv4 接続性を確保する方式として，4rd/SAM (RFC7600), MAP-E (RFC7597), DS-Lite (RFC6333) があると言われている。

MAP-E と DS-Lite については，JPNE と MF（ならびに MF 主要株主の IIJ）からそれぞれ技術詳細も出ており，確実にその方式を利用していることは明らかである。これらの方式については次を参照されたい。

あきみちさんが書いた『徹底解説v6プラス』https://www.jpne.co.jp/ebooks/v6plus-ebook.pdf
IIJ の技術ブログ「てくろぐ」https://techlog.iij.ad.jp/archives/1879

とくに，MAP-E は JPNE 以外の VNE も多く利用しており，おそらくフレッツ網で使える IPv4 over IPv6 で一番多い手法なのではないだろうか。

ということで今回の本題は，「BBIX は本当に 4rd/SAM を利用しているのか」です。

4rd/SAM

出典：https://www.ietf.org/proceedings/83/slides/slides-83-softwire-10.pdf

上記の図のように，4rd/SAM は 6rd がやることの逆のヴァージョンとして生まれ，MAP-E の前身となっている。そしてどうやら RFC7600 は草稿のまま放棄されているようだ。なので，4rd も MAP-E 同様に A+P (Address + Port) の 48-bit を IPv6 アドレスに埋め込んで stateless に IPv6 へ変換する，ISP 側ではなく CPE 側での変換技術らしい。

ではなぜ BBIX はこの放棄された 4rd/SAM を利用している，と言われているのであろう。

それはどうやら，BBIX の資料として 2010～2011 年に書かれた公開資料に，「BBIX、JPIX、IMF、IIJイノベーションインスティチュートの4社で共同仕様を作成し、技術検証を行なっています！」と書かれているあたりのようだ。 https://www.soumu.go.jp/main_content/000119430.pdf

ここで言う IMF は前述の MF のことであり，また，IIJイノベーションインスティチュート (IIJ-II) はつまり IIJ 技術研究所のことなので，MF の技術検証に研究所として協力しているのだと考えられる。そしてここには JPIX が名を連ねているが，JPIX のネイティブ接続業者としての権利は JPNE に譲渡されている

つまりこの資料は IPoE の初期の VNE 事業者 3 社が当初は共同して IPv4 over IPv6 の方式を仕様化しようと努力していた，という過去の事実が読み取れるだけで，実は BBIX が現在も 4rd/SAM を利用しているという根拠はない。

この記述のあるページには SAM についての BBIX からのプレスリリース http://www.bbix.net/press/file/press_20100831.pdf の URL も記述されているが，この URL は既に失なわれており，Internet Archive からもこの PDF 資料は取り出せなかったため，もはやどういったリリースだったかは完全に失なわれている。

いずれにせよ，BBIX が 4rd/SAM を利用している，というのはかなり根拠のない話だと考えられる。これは，先程見た 4rd の資料を見ても，4rd の仕様では MAP-E 同様にエンドユーザーに割り当てられたポートの範囲でしか「ポート開放」が出来ないというのに対して，ソフトバンク光の利用者は「IPv6 ハイブリッド」を利用していてもグローバルアドレスをまるまる一つ占有し，自由に IPv4 の NAPT が出来ている事実と符号する。よって，「BBIX では 4rd/SAM が IPv4 over IPv6 のため用いられている」はマチガイだと断言してもいい。

さて，重要なのは 10 年前に検討されていた事項ではなく，現在提供されているサーヴィスである

私は IIJ と契約し MF を通じてインターネットを利用しているため，実地で BBIX の検証をすることは望むべくもないが，インターネット上に出典不明の情報が転がっていた。

禿は独自プロトコル。トンネルはただのIPIPで、ユーザ側の専用ルータがIPv4のグローバルアドレスを占有し(他のVNEは共有)、トンネル終端と普通のNATをするだけ。だから所謂ポート開放ができる。 v4のアドレスは半固定で、RADIUS認証で取得している模様。
【風前の灯火】IPv6スレ ver10【IPv4NATに完敗】

もしかしたら『徹底解説v6プラス』の 6.3 で述べられている「v6プラスでの固定IPv4アドレスのサービス」に近いのかもしれない（これも IPv4 over IPv6 のトンネリングに MAP-E を使用しない

追記

本稿を公開したことによって BBIX COO の福智氏から「アドレス共有は行なっていない」という旨の言及を頂きました。その上で念のため，不躾ながら，「BBIX の IPv6 高速ハイブリッドサービスは RFC7600 に沿ったものか否か」について質問したところ，大変ありがたいことに BBIX は 4rd を利用していないという確認を頂けました。大変ありがとうございます。よって，「BBIX の IPv4 over IPv6 は 4rd/SAM である」は明確に間違いです。

弊社は4rdは利用しておりません。アドレス共有をしていませんので。
— Charlie Fukuchi (@bbix_mfukuchi) July 3, 2020

追記 2

BBIX ユーザーが 5ch 情報について追試して裏を取ってくれました。「ただの IPIP トンネル」「貰えるアドレスは RADIUS 認証によって配られる」「BR と CPE で NAT している」あたり間違いはないようです。

ミラーリング出来るハブを掴まえたのでキャプチャしました。RADIUS で認証したあとはただの IPIP トンネルっぽいです。ここにあるとおりでした https://t.co/aKWjI4GRmX
— Rokoucha (@rokoucha) July 3, 2020

MTU，MSS の計算と最適化の便利な手段をまとめる

2020-06-30T10:27:00.006+09:00

MTU/MSS の計算

IP ヘッダや Ethernet フレームの計算は結構大変だけれどもこのサイトを使えばわりとラクに導出できます。 https://baturin.org/tools/encapcalc/

たとえば MTU 1454 の環境（フレッツ網で ISP と PPPoE で接続した場合）の MSS は次の画像のとおり 1414 と計算可能です。

この MTU 1454 の根拠は，フレッツ網では PPPoE で接続する際，NTT の収容ビルから事業者装置までの間は L2TP で接続しており，そこで PPPoE ヘッダを認証用の PPP ヘッダだけ残して取り払い，PPP over L2TP の状態にすると，IP (20 byte) + UDP (8 byte) + PPP (2 byte) + L2TP (16 byte) = 46 byte なので，1500 - 46 = 1454 byte になります。参考サイト

さきほどのサイトでは L2TPv3 の計算はできるけど L2TP の計算が出来ないのが惜しいところ。

MTU の最適化

前述の手段で計算した値をルーターやクライアントに設定しても良いですが，既に通信が可能な環境ならばヒューリスティックに最適な MTU を導出することもできます。

ping コマンド

PS C:\Users\orumin> ping -f -l 1424 -n 1 8.8.8.8

8.8.8.8 に ping を送信しています 1424 バイトのデータ:
8.8.8.8 からの応答: バイト数 =68 (1424 を送信) 時間 =3ms TTL=119

8.8.8.8 の ping 統計:
    パケット数: 送信 = 1、受信 = 1、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 3ms、最大 = 3ms、平均 = 3ms

たとえば Windows なら，このようにして ping のパケットサイズを指定し DF ビットを立てます（＝分割を禁止する）。こうすると，MTU を超過するようなパケットを送出すると以下のようになります。

PS C:\Users\orumin> ping -f -l 1425 -n 1 8.8.8.8

8.8.8.8 に ping を送信しています 1425 バイトのデータ:
パケットの断片化が必要ですが、DF が設定されています。

8.8.8.8 の ping 統計:
    パケット数: 送信 = 1、受信 = 0、損失 = 1 (100% の損失)、

これで最適なサイズは 1424 だとわかりますが，この数字はデータサイズなので，ここに IP ヘッダ (20 byte) と ICMP ヘッダ (8 byte) を足した 1424 + 20 + 8 = 1452 byte が私の環境で最適な MTU となります。

これは IPoE で IPv6 を貰った上で IPv4 over IPv6 (DS-Lite) を利用している環境なので，MTU 1500 - IPv6 (40 byte) - encap_limit (8 byte) = 1452 です。https://www.spinics.net/lists/netdev/msg143874.html

ping のオプションについて，Linux と macOS（FreeBSD ユーザーランド）でのオプションはそれぞれ以下のとおり。

$ ping -c 1 -s 1424 -M do 8.8.8.8 # Linux
$ ping -c 1 -s 1424 -D 8.8.8.8 # macOS

traceroute コマンド

また，世の中には ~~Path MTU~~ Path MTU Discovery (ご指摘感謝 https://twitter.com/ichinose_iroha/status/1278822907053932544) というものがあり，途中経路で ICMP が破棄されない環境なら，ルーターが ICMP 経由で適切な MTU を返してくれることにより，MTU が自動で最適な値に設定できます。参考サイト

ここで，traceroute のコマンドオプションによって ~~PMTU~~ PMTU 探索を使って適切な MTU を取得することが可能です

$ traceroute -F -N 1 --mtu 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 65000 byte packets
 1  192.168.11.1 (192.168.11.1)  0.485 ms F=1500  0.456 ms  0.465 ms
 2  ike-gw10.transix.jp (14.0.9.78)  3.856 ms F=1452  3.530 ms  3.245 ms
 ..

F=xxxxの値を確認すると，最初に CPE で F=1500 として渡してますが，次に DS-Lite の AFTR で NAPT されたあとに返ってくる F= の値が 1452 になっており，この環境の適切な MTU が 1452 であることが把握可能です。

ちなみにこれを DS-Lite ではなく PPPoE 経由にしてみると，

$ sudo traceroute -F -N 1 --mtu -i enp2s0 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 65000 byte packets
 1  192.168.1.1  0.395 ms F=1500  0.408 ms  0.357 ms
 2  xxxxxxxxxxxxxxxx (xxx.xxx.xxx.xxx)  3.415 ms F=1454  3.373 ms  3.356 ms

たしかに F=1454 になっており，本記事冒頭で計算した MTU に合致していますね。

~~PMTU~~ PMTU 探索は便利ですが，PMTU を信頼してこちら側で MTU を指定していない時，途中経路に ICMP を返さないヤツとかが居ると Path MTU Black Hole になってしまい，こちら側で適切な MTU が設定できなくて TCP のセッションがタイムアウトするといった可能性があります (RFC2923) 参考サイト

最後に余談ですが，たとえば SINET などはジャンボフレームに対応しており MTU が 9140 bytes とされています（念のためちょっと少なめの 9000 byte あたりに設定することを推奨されています）。そのため，インターネットへの接続が SINET を経由している学術機関などではもう少し大きいパケットを送れる可能性があります。ただし大学→SINET のアクセス回線がフレッツの可能性もあるので，そこらへんは自分の所属機関に問合せたほうが早いでしょう。

grep で OR 検索，AND 検索

2020-06-06T11:46:00.001+09:00

OR 検索

grep -e 'pattern1' -e 'pattern2'
grep -e 'pattern1\|pattern2'
grep -E -e 'pattern1|pattern2'

AND 検索

基本的にムリ。

grep -e 'pattern1' | grep -e 'pattern2'

スマートではないが grep の結果を grep するのを何度も繰り返せば出来なくもない。

また，GNU grep は PCRE が利用できるのでそれを使えば

grep -P '^(?=.*pattern1)(?=.*pattern2)'

と書ける。

grep 以外で AND 検索

AND 検索のときはこっちを使うほうが良さそう。

awk '/pattern1/ && /pattern2/'

sed -e '/pattern1/!d' -e '/pattern2/!d'

出典

https://unix.stackexchange.com/questions/55359/how-to-run-grep-with-multiple-and-patterns

以上

メモ

PCRE は 1234，1324，1432，1423，2341，... のような {1,2,3,4} の順列にマッチする条件，とかも綺麗に書こうと思えば書けるらしい。マジかよ。 https://stackoverflow.com/questions/3101366/regex-to-match-all-permutations-of-1-2-3-4-without-repetition/3101385#3101385

ssh-rsa，非推奨のお知らせ

2020-05-28T12:41:00.009+09:00

2020-05-28T14:11+9:00 追記

これは SHA-1 を用いた RSA 鍵についての話で，OpenSSH 7.2 以降で生成・利用される RSA 鍵はまだ利用可能です

2020-05-28T19:27+9:00 追記

既に生成されている RSA 鍵でも~~ホスト・クライアントの両方が OpenSSH 7.2 以降~~ホスト・クライアントの両方が OpenSSH 7.2 以降，ただしサーバー側は OpenSSH 7.4 以外であれば SHA-2 で署名するので大丈夫なようです。（OpenSSH 7.4 はバグがあるようです）

ssh-rsaという名前は"公開鍵の形式"と"公開鍵を使った署名方式"の二つで使われていて、廃止対象となっているのは署名方式の方だけです。なのでOpenSSH 7.2以降を入れれば、鍵自体は古いOpenSSHで生成した物がそのまま使えます。
— いわもとこういち (@ttdoda) May 28, 2020

openssh-unix-devで指摘が出ていますが、OpenSSH 7.4のバグで、サーバ側が7.4だとrsa-sha2-256/512が使えると通知してこないのでssh-rsaでユーザ認証が行われてしまいます。これはユーザ認証時のみの問題で、ホスト鍵の確認には影響しません。 https://t.co/oyNVS08jGI
— いわもとこういち (@ttdoda) May 30, 2020

本文

OpenSSH 8.3 がリリースされたとのこと OpenSSH 8.3 released (and ssh-rsa deprecation notice) [LWN.net]

これに伴ない，ssh-rsa は将来的に deprecate になり，デフォルトでこの鍵形式を利用する機能自体が無効化されることが改めて告知されました。

サーバー側がこの形式を利用しているかどうを確認するには，`HostKeyAlgorithms` ディレクティヴから ssh-rsa を取り除いた上で以下のコマンドを使うこと

ssh -oHostKeyAlgorithms=-ssh-rsa user@host

`HostKeyAlgorithms` は ~/.ssh/config で利用する鍵形式を指定できます。

現在は SHA-1 ハッシュを用いているアルゴリズムが $50K 以下で chosen-prefix attack という手法で攻撃できてしまうことから，ssh-rsa も非推奨になるそうです。

なお，ssh-rsa と同じ形式の鍵ですが SHA-2 ハッシュを用いている rsa-sha2-256/512 は OpenSSH 7.2 からサポートされており，ほかにも ECDSA 形式の ecdsa-sha2-nistp256/384/521 が OpenSSH 5.7 から，ssh-ed25519 が OpenSSH 7.2 から利用できます。

ssh-keygen -t ecdsa
ssh-keygen -t ed25519

また，鍵生成のときは，以上に加えて， ssh-keygen -t rsa -b 4096，ssh-keygen -t ecdsa -b 521 というようになるべく大きな鍵長を指定するようにすると，より安全です。

Linux kernel のコードをパッチレベルを指定して入手

2020-05-22T17:39:00.001+09:00

URL を覚えていて手癖で簡単に入力できるという理由で Linux kernel を手元に持ってくるときにはよく

git clone https://github.com/torvalds/linux.git

をしてしまうのだが，ここで git checkout をマイナーバージョンまでではなくパッチバージョンまでのレベルで指定しようとすると，そのようなタグはないと言われる。

error: pathspec 'v4.1.8' did not match any file(s) known to git

これは GitHub にあるミラーレポジトリはリリース候補のタグしか置いてないためで，kernel.org にある linux-stable の Git レポジトリを利用しないとパッチバージョンのタグが打たれていない。

git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linu.git

このレポジトリを利用すれば，パッチバージョンでの変化や歴史を Git で追いたいときに便利だ。

$ git checkout v4.1.8
HEAD is now at 36311a9ec490 Linux 4.1.8

もっとも，Git の機能を利用せずコードを読むだけなら tarball をダウンロードするほうが手っ取り早い。

curl -LO https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.1.8.tar.xz

素の Windows からリモートホストの macOS や Linux にクリップボードのテキストを流す

2020-05-15T15:33:00.000+09:00

PowerShell で次を実行

$OutputEncoding = [Console]::OutputEncoding
Get-Clipboard -Format Text | ssh macOS_host "iconv -f sjis -t utf8 | pbcopy"
Get-Clipboard -Format Text | ssh Linux_host "iconv -f sjis -t utf8 | xsel --clipboard --input"

上記のコマンドで，リモートの macOS ホストと Linux ホストそれぞれのクリップボードにローカルのクリップボードのテキストが転送されます。

最初のほうで OutputEncoding を上書きしているのは，これをしないと Get-Clipboard コマンドレットの出力が us-ascii でエンコードされるので，クリップボードの中身が日本語だと化けます。ちなみに ASCII のテキストなら

Get-Clipboard -Format Text | ssh macOS_host "pbcopy"

だけで済む。

逆に，macOS や Linux のホストのクリップボードを手元に持ってきたいときは，macOS なら pbpaste，Linux なら xsel --clipboard --output を使ってください。

あと言わないでもわかることだとは思うけど，PowerShell の Get-Clipboard/Set-Clipboard コマンドレットや macOS の pbcopy/pbpaste コマンドはデフォルトで使えますが Linux の xsel コマンドは自分でインストールしなくても必ず存在するとは限りません。

ちなみに，とくに Windows ホストに外部コマンドをインストールしてはいけない縛りとかないのなら，win32yank を導入するのはオススメ。

Oculus Quest と Virtual Desktop でモニタが一枚しかない部屋でマルチモニタを実現したい

2020-05-12T19:09:00.000+09:00

前提

VR HMDで VR 空間に埋没してかっこいい空間を広々使ってお仕事したい
現実世界の PC がモニタ 1 枚しかない
画面出力端子を適当なドングルで埋めて fake monitor を召喚する手もあるがソフトウェアで解決したいところ

どういうことなのか

実は去年末に Oculus Quest を購入していました。そのうち記事にするかも。それはそれとして，Oculus Quest を買ったのは『狼と香辛料 VR』が気になってた，というのと，サイバーパンクでありがちな，半透明のウィンドウが自分を取りかこむようにぶわーっと浮いて広がってるやつ，あれをやりたいという理由でした。

みなさんお気付きかと思いますが，後者の目的なら HoloLens とか買うほうが実現しやすいとは思います。でも高い。しかし Oculus Quest はスタンドアローンで 6DoF なワリには安い。それに Oculus Go を買うぞ買うぞと言い続けて結局 Oculus Quest 開発中の発表を見てしまったので，発売したら絶対買うぞ！と思ってました。それでいい加減に腹決めて買ったのが去年末。

で，VR 世界でデスクトップ環境を実現する方法はいくつかあります。たとえば私の理想に近いのは Linux のデスクトップ環境である SimuraVR でしょう。しかしこれは HTC Vive か Vavle Index あたりでしか利用できないようです。Oculus Rift S なら OpenXR に対応しているので，かろうじて使えるようですが，Oculus Quest は PCVR に対応しているとは言えども Oculus Link が必要で，この Oculus Link は Windows の Oculus ランタイムアプリに依存しています。血も涙もない。

故に Oclus Link+Virtual Desktop で，なんとかマルチモニターを仮想的に実現して気分を良くしたかったのでした。

やりかた

ハードウェア

素直にやるなら，ハードウェアでごまかすことが手っ取り早いです。

有名な手段としては，GPU の DP 端子に DP→VGA 変換器を取り付けて，Dsub 15-pin の VGA 端子，これの 2-pin と 7-pin を 102Ω 抵抗で結線します。こうするとモニタが接続されていると誤認識されるのです。PowerPC Mac に Linux を入れてヘッドレスで運用しようとしたときもコレ必要でした。しかしこのために VGA 変換ケーブル用意したり工作するのはやや面倒で，しかも解像度が限定されるでしょう。

次に考えられるのは，Headless Ghost あたりの，fake monitor（あるいは ghost monitor）を Windows に認識させる専用のドングルを利用することです。これは 4K ディスプレイが接続されていると誤認させてくれる回路が積んである HDMI 端子のドングルですが，同様のドングルは様々な端子であちこちで発売されているようです。Amazon とか Aliexpress で色々ありました。

ソフトウェア

とはいえ私はそれをすぐに実現したい，できなかったらすぐ諦めるぐらいの気持ちだったので，ソフトウェアでの解決を試みました。よくあちこちで書かれている手段としては，Windows のコントロールパネル，画面解像度の設定にて，「画面の検出」を押したのちにアレコレすると VGA driver な fake monitor を用意することができる，というもの。しかしこれは Windows 10 の近年[いつ？] の ver. では使えません。そもそも画面設定がついにコントロールパネルからオミットされました。

なのでここで最終的に利用した手段を書きます。SpaceDesk という driver とアプリを用いる方法でした。ドイツ・バイエルン州のアウクスブルクに本社がある datronic という会社のソフトウェアだそうです。まずこれの driver をインストールし，その後 Google Chrome で http://viewer.spacedesk.net このページを開きます。すると IP アドレスの入力画面が登場するので，自身の PC のローカル IP アドレスを入力してください。

ここでブラウザが全画面になり，二つめの画面の中身が登場すると思うので，いったん ESC を押したりして抜け出してください。そのあと，このページの左上のハンバーガーボタンを選択すると設定が選べます。設定の中で「Use Client Resolution (for Extension)」などにチェックを入れればよろしかろうと思います。

もし画面が拡張ではなく一つ目の画面の複製になっていたら，「Super（Winキー，あるいは Cmd キーとも言います）+P」を押して「拡張」を選ぶと解決

追伸

ひさびさに Blogger 開いたら記事編集画面がめっちゃ fancy になってて驚いた。正直微妙。それと最近雑誌に記事書きました。技術評論社の『Software Design』，2020 年 5 月号です。初商業出版の記事，そちらもよろしければご一読ください[link]。それと，そのうち SimuraVR っぽいことが Oculus Quest で出来るようになったら誰か教えてください……。

Rockbox のダーティーハック（複数の値を持つ音楽メタデータへの対応）

2020-02-07T00:15:00.000+09:00

本日誕生日のおるみんです。

みなさんは Rockbox というファームウェア／カーネルをご存知でしょうか。単一メモリ空間，シングルプロセスで動作するファームウェアで，簡単なスレッドスケジューラを備えることによってマルチスレッドで動作可能な，主にディジタルオーディオプレイヤー（DAP）上で動作するオープンソースファームウェアです。

初期には仏 Archos 製の MP3 プレイヤーに不満を持ったユーザーが homebrew プログラムの動作方法を見つけ，独自実装したのが始まりで韓国 iriver 製 DAP や米 SanDisk の Sansa，東芝の Gigabeat シリーズなど様々な DAP へ porting されています。

わけても初期のSony ネットワークウォークマンや大半の米 Apple iPod シリーズにも対応していることで，2000～2010 年ごろの DAP ユーザー（のごく一部）に広く知られています（広く？）。

Rockbox の場合，iPod の純正 Apple OS と違い Album Artist タグに対応してますし FLAC は再生できますし crossfeed やパラメトリックイコライザ（low-shelf，high-shelf，peaking * 8 の合わせて 10 バンドで Q 値も設定できる）など再生時のパラメータも細かく設定できるため，ギーク向きの良いファームウェアなのですが，不満もあります

何をしたいか

ここまで前置き，本題は Rockbox は意図的に複数の値を持つタグを読み捨ててしまうというところです。

音楽のメタデータは MP3 や AAC に対応する ID3 タグが知られていますが他にも Ogg Vorbis や FLAC に対応する Vorbis Comment，Monkey's Audio に対応する APE tag などが存在します。

ID3 タグの場合は ID3v2.3 だとスラッシュ，ID3v2.4 だとヌル文字を区切り文字にし複数の値を書いていけば良いという仕様がありますが，今回の記事では考えないことにします。今回は FLAC で使われる Vorbis Comment について複数の値に対応する方法を考えてみたいと思います。

Vorbis Comment

Vorbis Comment の細かい仕様は仕様書を見てもらうとして，簡単には次のようになっています。

TITLE=Canned Heat
ALBUM=Synkronized
ARTIST=Jamiroquai
...

<key, value> という構成になっているだけの至極単純なもので，key のほうは大文字小文字を区別しません。さて，これがどのように複数アーティストに対応するかというと，次のようになります。

TITLE=Yes! Party Time!! (M@STER VERSION)
ALBUM=THE IDOLM@STER CINDERELLA GIRLS VIEWING REVOLUTION Yes! Party Time!!
ARITST=島村卯月(大橋彩香)
ARITST=渋谷凛(福原綾香)
ARITST=本田未央(原紗友里)
ARITST=赤城みりあ(黒沢ともよ)
ARITST=安部菜々(三宅麻理恵)
...

このように同じ key 名の値を複数並べていくだけです。ね，簡単でしょ？

処理をかんがえる

簡単なわけがない。ある key 名が 1 つだけ来るかもしれないし，100000000 コくるかもしれない，それをパーサーは予期できない。しかも key の名前は推奨されるものはいくつかあるけれども，規格で決まってるわけではない。ID3 タグと違ってかなり自由度の高いメタデータが記述できるのはメリットではありますが，いくら事細かにメタデータを記入したところで読み出し側がちゃんと処理してくれなければ絵に描いた餅です。

さて，Rockbox が動作するプラットフォームは大抵メモリや CPU が貧弱極まりないため（iPod classic はかなり良いほうですね），メモリを潤沢に扱えません。そのため，Vorbis Comment については，同じ key 名が来たら読み捨てる，という手段を取ります。また，読み込んだメタデータについても，ID3 タグを念頭に置いている struct mp3entry という構造体のメンバのひとつである単一の文字配列をバッファとして全てここに読み込んでしまい，この構造体の artist や title といった名前のメンバはそのバッファへのポインタになっています。各タグの間はヌル文字で仕切る，というわけです。（rockbox/lib/rbcodec/metadata/metadata.h#L233 を参照のこと）

しかしならば話はある意味簡単です。いままで読み飛ばしてた処理のところで，読み飛ばさずに追記してしまえば良いのです。

実装

行なった実装は次のとおり。コードはわりと読み易く，改変も簡単なものなので，ものの数分でやりたいことは完了した気がします。この記事を書くほうが時間がかかったぐらいです。ごらんの通り，以前読んだ key がやってきたら，スラッシュを区切り文字代わりにして新しい値をもうひとつ追記しています。こうすると，例えば複数のアーティストについて，

島村卯月(大橋彩香) / 渋谷凛(福原綾香) / 本田未央(原紗友里) / 赤城みりあ(黒沢ともよ) / 安部菜々(三宅麻理恵)

のように複数の値が 1 つの連結された文字列として格納されるため，結果として複数アーティストがきちんと iPod に表示されるわけです。やったね！

ところで勘の良いかたはお気付きかもしれませんが，この方法だと Vorbis Comment として

ARTIST=CHAGE
TILTE=YAH YAH YAH
ARTIST=ASKA

みたいなメタデータがやってきた場合，おそらく文字列を格納する順番から考えて TITLE の文字列の一部が上書きされてしまい，かなり微妙な読み出し結果になってしまうでしょう。つまりこのパッチはかなり雑なやりかたです。ダーティーハックですね。（ところで CHAGE and ASKA はたぶん ARTIST を分割して複数値にしたりはしないと思うのでこの例はかなり微妙ですね）

ですが良いのです。まともな頭がついてればメタデータを書き込むほうだって同じ key は連続して書くでしょう。少なくとも自分がデータ管理している foobar2000 では ; セミコロンを区切り文字にすれば ID3 タグではスラッシュやヌル文字，Vorbis Comment なら複数 key と欲しいデータをいい感じに書いてくれるみたいなので，たぶん気にしなくても良いはずです。少なくとも自分の環境ではうまくいきました。

何がうれしいの

ぶっちゃけ iPod の表示が欠けてたって何も困らないのですが，Rockbox が last.fm 向けに生成する scrobbler ログに複数アーティストが歌う曲が単独アーティストかのように間抜けに書かれて last.fm にヘンなログが残るのが無くなりました。

そのうち気分転換のコード書きたくなったらやりたいこと

とりあえず複数の値は / 区切りということで読み出してしまったので，Rockbox のデータベース生成のルーチンを書き換えて / 区切りでデータベースの値を生成したら，複数のアーティストが 1 つの文字列に連結されていてもデータベース上は複数の値として扱われるので曲の検索に便利そうです。そしてそれほど難しくないかもしれない。

app/tagcache.cを書き換えればいいのかなあ。まあいつかやりたいですね，いつか……。

Makefileの基本的な書き方について

2019-12-03T14:05:00.000+09:00

最近研究室Wikiに後輩向けの文章書いてたのですが，いくつかはclosedにするのも勿体無いので編集してブログで公開しようかと思います。

概要

Makefile は自分の書いたコードのビルドの自動化に便利なため基本的な記法は知っておくとよい
- いちいちシェルの履歴を確認したりコマンドをミスする悲しいことがなくなる
Makefile はビルドだけでなく実験やらなんやらの task runner としても便利
- ビルド・実験を回す・結果をグラフにする，などをまとめてやったりすることも可能
上記は shell script でも可能だがメリットとして
- あるタスクに対して依存関係が記述できる
  - 実験タスクの依存にビルドタスクを記述すれば，実験タスクを実行したら自動でビルドしてくれる
- あるタスクについて，依存先が更新されていなければ実行しないという機能が標準で存在
  - 二行上のような依存を記述していたときに，ソースコードの更新の有無でビルドの実行をする／しないを勝手に判断してくれる
以下の説明は GNU Make に準拠して説明を行う。BSD Make の場合上手く動作しない記法も含まれる

Makefile の基本的な利用法

TARGET := prog
CC := /usr/bin/gcc
CFLAGS := -g -O2 -Wall
RM := /bin/rm

$(TARGET): main.c
    $(CC) $(CFLAGS) $< -o $@

clean:
    $(RM) -rf $(TARGET)

all: $(TARGET)

.PHONY: all clean

上記は最も基本的な Makefile の記述のひとつ。ひとつひとつ見ていく

Makefile の変数

Makefile はシェル変数とは別に独自の変数を持つ。:= で変数を定義し，$(VAR) のように記述して展開する。また，変数は = でも定義が可能だが，:= と = は定義式の評価のタイミングが異なるなど差異が存在する。具体的には = を用いると値が決まるのが実際に参照されるときになる。 Makefile のタスクの中でシェルの環境変数（$PATH など）を展開したい場合は $$PATH のように $ をエスケープする必要がある。

Makefile の変数は := の代わりに += を使うことで，既に存在する変数に追記することができる。

また，Makefile（とくに GNU Make）には多種多様な関数や機能が用意されている。一例として，

SRC  := main.c test.c test2.c
OBJS := $(SRC:.c=.o)

と記述すると，$(OBJS) の中身は main.o test.o test2.o になる。

Makefile のタスク

タスクは ターゲット: 依存先 という風に記述する。最初の節にある Makefile の例をみてみると，

$(TARGET): main.c
    $(CC) $(CFLAGS) $< -o $@

と書いてある。この中に書いてある変数を全部展開すると，

prog: main.c
    gcc -g -O2 -Wall main.c -o prog

となる。つまり，prog という実行ファイルは，main.c というファイルに依存しているという記述である。このタスクの中身は，タスクの依存関係の次の行からインデントしてシェルスクリプトを記述することになる。この例では

$(CC) $(CFLAGS) $< -o $@

となっている部分である。タスクが複数行ある場合は，

target: deps
    mkdir -p test
    cd test && touch testfile.txt

のように全てインデントを行なう。注意しなければならないのは，このインデントはソフトインデント（半角スペース）ではなくハードインデント（タブ文字）でなくてはならない。また，このタスクは実際には

target: deps
    sh -c "mkdir -p test"
    sh -c "cd test && touch testfile.txt"

のように一行ごとにシェルが別々に起動して実行されるため，

target: deps
    mkdir -p test
    cd test
    touch testfile.txt

と記述すると意図通り動作せず失敗してしまう。

Makefile の疑似ターゲット

例示した Makefile では .PHONY: all clean と記述してあり，また，依存が存在しないタスク clean や $(TARGET) を依存に指定するタスク all が記述してある。.PHONY: で指定したタスクは擬似的なターゲットである。

これは all や clean といった名前のファイルを作るタスクではないことを明示している。というのも，Makefile のタスクは一般的にターゲットと同じファイル名のファイルを生成するタスクを記述するツールであるためだ。

Makefile の挙動として，タスクのターゲットに指定しているファイル名が存在しないとき，または依存先が更新されていた場合，このどちらかが真であればタスクが実行されるということになっている。しかし，プロジェクトのビルドではなく，この clean ターゲットのようにただのタスクを記述したいときにそれでは不便なため，このように .PHONY: を用いて擬似的なターゲットを作ることで解決している。

ちなみに，make コマンドは引数にターゲットを指定するが，引数を渡さずにただ make とだけ打った場合は暗黙的に make all を実行したことと同じと見なされる。

Makefile の特殊な変数

Makefile のタスクの例にて，$< や $@ という変数を利用した。これは Makefile が自動的に定義する特殊な変数である。

TARGET: DEP1 DEP2
    なんかのタスク

というタスクを用意したときに，$@ は TARGET として展開される。また，$^ は DEP1 として展開され，$< は DEP1 DEP2 という風に展開される。他にも自動変数は複数あるが，基本的にこのみっつを覚えておけば良い。

Makefile の発展的な記述方法：サフィックスルール

TARGET := prog
CC := gcc
CXX := g++
CFLAGS := -g -O2 -Wall
CXXFLAGS := $(CFLAGS)
LD := ld
LDFLAGS := -lc -lm -lpthread

SRCS := main.c library1.c library2.c
OBJS := $(SRCS:.c=.o)

.SUFFIXES:
.SUFFIXES: .c .o

.PHONY: all

all: $(TARGET)

.c.o:
    $(CC) $(CFLAGS) -c $^ -o $@

$(TARGET): $(OBJS)
    $(LD) $(LDFLAGS) $< -o $@

Makefile の発展的な記法として サフィックスルール が存在する。上記の Makefile を見てほしい。

make コマンドを実行したとき，自動で all ターゲットを実行するため，この場合は all: $(TARGET) という疑似ターゲットによる依存関係をみて，$(TARGET): $(OBJS) という依存関係が記述されたターゲットのタスクを実行することになる。

しかし，この時依存関係には $(OBJS) しか書いていない。この $(OBJS) 変数はこの定義だと main.o library1.o library2.o と展開されるが，この .o 拡張子を持つオブジェクトファイルをどのソースコードからどう生成するかという依存関係は一切記述されていないのである。

これは実は，.c.o: と書かれているターゲットで解決される。これをサフィックスルールと呼び，この場合，.o という拡張子であれば自動的に同名で拡張子が .c となっているファイルから生成するよ，ということを言っている。

このサフィックスルールの場合は gcc に -c オプションを追加しているため，結果としてソースコードが 1 ファイル単位でオブジェクトファイルにコンパイルされ，$(TARGET): $(OBJS) のタスクでは生成された全てのオブジェクトファイルを ld コマンドによってリンカーがリンクしているのである。

この方法だと，複数のソースコードのうち一つのファイルだけが変更された時，そのファイルのコンパイルと全体のリンクだけが走り，全てのファイルを全てコンパイルしなおさなくて済む（＝差分コンパイルが可能）という点でメリットがある。

Makefile の task runner としての利用方法

基本的には前章で説明した方法を応用し，疑似ターゲットを作りつつそのターゲットに依存関係を追加すれば，プロジェクトのビルド以外の仕事も依存関係を考慮して実行できるということになる。

次に示すのは Markdown で記述されたファイルを LaTeX へ変換した上で PDF へ typeset（コンパイル）するタスクと，make preview によって生成した PDF を PDF ビューワーで閲覧するタスクが定義してある筆者作の Makefile である。

実際には LaTeX には latexmk という Perl 製の便利な typeset スクリプトが標準に存在するため，実際に LaTeX を記述する際には PDF の閲覧にも typeset にもそちらを用いてほしい。あくまで Makefile の応用の一例である。

TEX=platex
PANDOC=pandoc
BIBTEX=pbibtex
DVI2PDF=dvipdfmx
TEX_FLAGS= --shell-escape -kanji=utf8 -kanji-internal=utf8 -interaction=batchmode

UNAME=$(shell uname)
ifeq $($(UNAME), Darwin)
    VIEWER=open
else ifeq $($(UNAME), Linux)
    VIEWER=xdg-open
else ifeq $($(OS), Windows_NT)
    VIEWER=start
endif

TARGET=paper

COUNT=3

SOURCE = manuscript.tex

MDSCRIPTS = src/abstract.md src/contents.md

TEXFILES=$(MDSCRIPTS:.md=.tex)
DVIFILE=$(SOURCE:.tex=.dvi)
BIBFILES=cite/paper.bib
REFSTYLES=sty/crossref_config.yaml

PANDOC_FLAGS= --smart -f markdown+pipe_tables -t latex --filter pandoc-crossref --natbib

PANDOC_FILTER_FLAGS= -M "crossrefYaml=$(REFSTYLES)"

.SUFFIXES: .tex .md .pdf
.PHONY: all semi-clean clean preview

all: $(TARGET).pdf semi-clean

.md.tex:
 @cat $< \
 | $(PANDOC) --verbose $(PANDOC_FLAGS) $(PANDOC_FILTER_FLAGS) \
 | sed 's/.png/.pdf/g' \
 | sed 's/includegraphics/includegraphics[width=1.0\\columnwidth]/g' \
 | sed 's/\[htbp\]/[t]/g' \
 > $@

$(TARGET).pdf: $(TEXFILES)
 @cd tex && for i in `seq 1 $(COUNT)`; \
 do \
  $(TEX) $(TEX_FLAGS) $(SOURCE); \
  if [ ! -e "$(SOURCE:.tex=.blg)" ]; then \
   $(BIBTEX) $(basename $(SOURCE)); \
  fi \
 done
 cd tex && $(DVI2PDF) -o ../$(TARGET).pdf $(DVIFILE) 2> /dev/null

semi-clean:
 @cd tex && rm -f *.aux *.log *.out *.lof *.toc *.bbl *.blg *.xml *.bcf *blx.bib *.spl

clean: semi-clean
 @rm -f $(TARGET).pdf $(DVIFILE) $(TEXFILES)

preview:
 @$(VIEWER) $(TARGET).pdf 2> /dev/null

ちなみに，タスクの先頭に @ がついてる行があるが，これを行うと実行したコマンドが表示されなくなる。

計算機科学（一部分野）の論文の探しかた・投稿先の探しかた

2019-05-29T19:01:00.004+09:00

Google scholar や CiNii で検索しろなどという論文一般の探しかたはもう言われ尽くしてるので，CS（の一部の分野）に限った話をします。

論文

まず論文の探しかたとして，https://jeffhuang.com/best_paper_awards.html が 1996 年以降のベストペーパーを分野を横断して掲載しています。分野ごとにトップカンファレンス 1 つしか掲載していないので網羅的ではないですが，面白い論文を探してるのなら手軽に探せると思います。

なんならここから見つけた会議名や論文についてる reference から芋蔓で他の論文探せますしね。

あとは IEEE Xplore や ACM Digital Library で検索するととてもよいですね。 IEEE や ACM が主な戦場ではない CS の分野はたくさんあると思いますが，私はそれらについて詳しくないので詳しい人に任せます。

また，検索した論文のカンファレンスが分野でどのぐらいの位置付けなのか，あるいは，この分野についてどういうカンファレンスをみればよいのか，というので，

これらのようなカンファレンスのランクが検索できるようなサイトでカンフェレンスの格付けが確認できます。ジャーナルについてもランクが出てきますが。

最後に，普段から読んでる論文を Mendeley に登録しましょう。Mendeley が論文を suggest してくれるようになります。なんならたまにメールとかで suggest をまとめて送ってくれます。

投稿先

先程も出したカンファレンス格付けサイト，これはひとつの参考になります。また，これは完全に OS や DB といった CS のうちシステム系に限定した話なのですが，

http://www.cs.technion.ac.il/~dan/index_sysvenues_deadline.html

テクニオン（イスラエル工科大学）の Dan Tsafrir 准教授がまとめていらっしゃるこのサイトが非常に有用です。システム系の主要な会議が網羅的に書いてある上に，それぞれの締切日と開催日が載っています。

追記

OS 系会議リスト https://www.os.ecc.u-tokyo.ac.jp/conf.html
東大の品川准教授によるリスト。Tsafrir 准教授のものよりさらに OS に絞ってあるので，システム系でも特に OS 分野だけに絞るのならこっちのほうが見易そうですね。紹介ありがとうございました。

セキュリティ系の会議リスト
阪大宮地研究室が公開しているリスト https://cy2sec.comm.eng.osaka-u.ac.jp/miyaji-lab/announce/ranking-jp.html やテキサス A&M 大学の Guofei Gu 教授が公開しているリスト http://faculty.cs.tamu.edu/guofei/sec_conf_stat.htm があるそうです。須崎先生，紹介ありがとうございました。

よかったら、こちらもご参照ください。OS 系の国際会議をリストアップしています。https://t.co/Ti6M0WEK9x
— 品川高廣 (@utshina2) 2019年5月29日

OS 系の国際会議をリストは参考人させていただいてます。https://t.co/PszRQST3DK

その他、つい最近参考にした国際会議リスト(セキュリティ系)
大阪大学宮地研学会ランキング　https://t.co/8uBoYqLiRL
"Computer Security Conference Ranking and Statistic" by Guofei Guhttps://t.co/NKo02vqZ2w
— suzaki (@KuniSuzaki) 2019年5月30日

コマンドラインでメール／GPG で暗号化と復号

2019-05-29T00:00:00.002+09:00

msmtp と msmtp-mta をインストールすると sendmail 互換のコマンドが生えるため CLI からメールがサクっと送れる。これは Git で ML に patch に送る際に便利である。

defaults
auth    on
tls     on
tls_trust_file /etc/ssl/certs/ca-bundle.crt
logfile ~/.msmtp.log

account         gmail
host            smtp.gmail.com
port            587
from            [email protected]
user            example
passwordeval    "gpg --quiet --for-your-eyes-only --decrypt ~/.msmtp-gmail.gpg"

account         outlook
host            smtp.office365.com
port            587
from            [email protected]
user            [email protected]
passwordeval    "gpg --quiet --for-your-eyes-only --decrypt ~/.msmtp-outlook.gpg"

account default : gmail

こういう風に設定を書いておけばよい。また，この際に password に平文でパスワードを書くこともできるが，passwordeval として暗号化されたファイルを復号するコマンドを記述すると，パスワードを暗号化し別に扱えるので便利である。

さて，ここで GPG の暗号化なのだが，暗号化のコマンドは以下の通り

➤ gpg --encrypt -o ~/.msmtp-gmail.gpg -r [email protected] -
password
^D

-r に指定するメールアドレスは自分の GPG 秘密鍵に登録してあるメールアドレスである。コマンドの末尾に - を指定しているので標準入力から暗号化するテキストを入力することになり， Ctrl-D で入力を打ち切る。この例では「password」という文字列を暗号化して ~/.msmtp-gmail.gpg に保存することになる。

しかしここでハマりポイントがある。

gpg: XXXXXXXX: There is no assurance this key belongs to the named user

などと言われる場合だ。他所のマシンから秘密鍵を持ってきて import したときなどに起きる。これは自分の鍵を信用する設定にし忘れているため，

➤ gpg --edit-key XXXXXX

と鍵のシグネチャを指定し edit-key をすれば良いのだが，

gpg: can't do this in batch mode

と言われるのだ。これは昔には起きなかった気がする（どうして……）

➤ gpg --command-fd 0 --status-fd 1 --expert --edit-key XXXXXXXXX
[GNUPG:] KEY_CONSIDERED XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0
Secret key is available.

...(略)...

[GNUPG:] GET_LINE keyedit.prompt
trust
[GNUPG:] GOT_IT

...(略)...

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu

[GNUPG:] GET_LINE edit_ownertrust.value
5
[GNUPG:] GOT_IT
[GNUPG:] GET_BOOL edit_ownertrust.set_ultimate.okay
y
[GNUPG:] GOT_IT

...(略)...

[GNUPG:] GET_LINE keyedit.prompt
quit
[GNUPG:] GOT_IT

このように， --command-fd と --status-fd などをそれぞれ標準入力，標準出力にし，あとは，「trust 5 y quit」と順番にコマンドを入れていけばよい。