読者です 読者をやめる 読者になる 読者になる

i3 likeなwayland compositorのswayを使ってみている

Wayland何度か試してみてまあぼちぼち動くが、いいdesktop環境にはなってないなという感じだった。そんなところへ、いま使っている普通のタイルWMなi3とcompatibleなswayというwayland上desktop環境(wayland composiotr)を見つけたので試している。いまのところ結構いい感じに使えている。

github.com

インストールして、とりあえず起動してみると、i3のconfigを読んでいるらしく、いままで通りに使える。べんりだ。

そのままでも、だいたい動くんだけど、 .i3/configから.sway/configにcopyして調整した方がいい。

ちゃんと動くの?

わりとだいたいのものが動いている。Firefoxで動画とかも見れている。i3と操作が変わらないので、悪くなった感じはあまりない。

時々、GPU hangして落ちてしまって困るけど、これはXの時でも起きてるし、そもそもkernelがRCだからそっちもあやしい。ただ、Xの時はcompositorであるcomptonが死ぬだけで、i3は大丈夫なんだけど、swayだとGPU hangしたらswayごと死んでしまう。しかたないけど。

アプリは動くの?

swayはwlcというwayland compositorを作るlibraryを使っていて、これがXWaylandを立ててXのものもWaylandに乗せて動かしてくれるっぽい。べんり

X固有のものは?

Xに依存したものとして、xrandrとかxbacklightコマンドがある。これらは当然Wayland上で動かないので置きかえる必要がある。

xrandrに対応する機能はswayのconfigで実現できている。

HDMI接続の画面だったら

output HDMI-A-1 res 1920x1080 pos 1920 0

 のように書いておくと、メイン画面の右側になる、という感じ。

configに書いてなくても、

swaymsg -t command output HDMI-A-1 res 1920x1080 pos 1920 0

 というコマンドで動的に認識できる。

画面の名前は

swaymsg -t get_outputs

で、出てくるJSONを見ればわかる。

xbacklightコマンドは使えないので、適当に/sys/class/backlightを使ってがんばる。多分、時間が経ったら画面が消えるとかも現状ない感じがする。

あとタスクトレイが現状動いていない。まあなくてもいいやってことで忘れている。

壁紙は?

これもswayのoutputコマンドで設定できる

swaymsg -t command output eDP-1 bg wallpapers/foo.jpg fit

 こんな感じ。

i3との違いは?

i3でlauncherとしてrofiを使っている。これがswayだとうまく動かない。floatしてるwindowに対して入力できない?っぽい。裏にwindowいると、入力できるのでinputの当たり判定かなんかだろうか。"-normal-window"引数つけておけば動くのでそうしてる。

Rofi

入力deviceの設定も、swayのconfigで出きる。こんな感じ。device nameは"swaymsg -t get_inputs"で

input "2:7:SynPS/2_Synaptics_TouchPad" {
  accel_profile adaptive
  natural_scroll enabled
}

ところでWaylandのよさは出てるの?

よくわからない…。結局ほとんどのものはXWayland経由になってるし、directにwaylandしゃべってるやつは多分いない。入出力まわりよくなってんのかな? 劇的な体感はないけど、まあおもしろいし動くし使ってみている。Waylandでこんな動くんだな、と思うと楽しいのは楽しい。

「SDカード向け」ではないSDCardFSの正体

最近GoogleがSDカード向けにファイルシステムを作っている, というような話がありました.

juggly.cn

記事中に

ファイルシステムのネーミングからして、SD Card FS は SD / Micro SD カード専用のファイルシステムだと見られます。

とありますが, sdcardfsはそんな文字通りに「SDカードをターゲットにした」ものではありません.

そもそも

アドバンテージとして挙げられたのは一連のファイル操作のシステムコールをユーザー空間を行き来することなく実行できることで、一連の命令はカーネルとハードウェアの間でダイレクトにやり取りされ、これにより、コンテキストスイッチの影響を受けることがなくなり、ファイル操作のパフォーマンスが大幅に向上するそうです。

この部分がなんか変です. 普通「ユーザー空間を行き来」なんてしません. なにか間違って伝わっているような気がします.

では, SDCardFSとはどういうFSなのか, なぜ「SDカード性能が向上する」と言われているのか解き明かしていきます.

"/sdcard"の呪い

初期のAndroid端末の多くにはSDカードを挿すスロットがついていました. SDカード中のファイルへは, "/sdcard"からアクセスできました. アプリは"/sdcard"の下にファイルを作り, 読み書きすることで端末内部の「小さい領域」を節約して, 「外部デバイスの広い領域」を活用することができました.

結局, 多くのAndroid端末がSDカードスロットを持たなくなったようです*1. そのような端末でも, "/sdcard"は存在しています. この領域はSDカードを指す代わりに, 端末内部のストレージを指しています. こうしておけば, 外部ストレージを使いたいアプリが, SDカードの有無にかかわらず同じように動作することができますね.

一般にSDカードはVFATでフォーマットされています. 一方, Android (Linux)で用いられるファイルシステムExt4(時々F2FS)です. VFATとExt4とは機能に違いがあります. 特に2つの大きな違いがあります.

1つ目は, ファイル名の大文字・小文字の扱いです. VFATではファイル名中の大文字・小文字を区別しませんが, Ext4では大文字・小文字が厳密に区別されます. たとえば, "cat.JPG"という猫の画像ファイルを保存したとします. VFATであれば"JPG"を小文字にして, "cat.jpg"でアクセスしてもファイルを読むことができます. 一方Ext4では, "cat.jpg"でアクセスすると"JPG"部分の違いから, そんなファイルはない!と言われてしまいます.

2つ目の違いは, アクセス権限の取扱いです. Linuxファイルシステムでは伝統的なUNIXのファイルアクセス制御が使われています. すなわち, 各ファイルにその所有者, 所有グループがあり, 所有者・所有グループ・その他のユーザがそれぞれ読みこみ・書きこみ・実行の何ができるかがファイルシステムに記録されています. 一方で, もともとMS-DOSファイルシステムであるVFATには, そのようなアクセス権限情報は記録することができません.

1つ目の大文字・小文字の取扱いの違いは, Ext4上でアプリの互換性に影響をおよぼします. これまで「全部小文字でもアクセスできてた」アプリが, "/sdcard"が内部フラッシュを指す端末では急に動かなくなります. アプリの互換性はなるべく守らなければなりません.

2つ目のアクセス権限の違いは, VFAT上でAndroidにおけるセキュリティ機能の制限を生んでしまいます. Androidのセキュリティの詳細は割愛しますが, WRITE_EXTERNAL_STORAGEという権限を持ったアプリは"/sdcard"下のデータを読み書きすることができます. VFATの場合, ファイルの所有者がどのアプリかを記録できないので, OSレべルではアプリは"/sdcard"下のどんなファイルでも読めてしまいます. すなわち, 他のアプリの"/sdcard"下のデータを「盗み見る」ことも可能となってしまいます. とは言え, 「広いSDカード領域」を活用するためには, この権限が必要となるわけでアプリとしてはこの権限を要求しないわけにもいきません.

ここでジレンマに陥ります. 互換性を保とうと思えば, Ext4(などLinux固有のファイルシステム)を使うわけにはいきません. 一方でVFATではセキュリティ機能がうまくいきません. はてさて, どうしましょう.

ファイルシステムの「ラッピング」

VFATがアクセス権限を保存してくれない? なら, 動的に「アクセス権限を合成」してやればいいんじゃよ.

VFATでLinuxのセキュリティチェックをうまく適用できないのは, VFATがファイルの所有者情報を付けてくれないせいです. ならば, VFATをラップして, 所有者情報を付けてあげれば, OSのセキュリティチェックが適切に動きます.

イデアはこうです.

  • "/sdcard"下に, アプリごとにディレクトリを作る
  • アプリ固有のディレクトリ下のファイルに, アプリの所有者情報を合成する
  • アプリは自分のディレクトリの下なら自由に読み書きできるが, 他のアプリのファイルにはアクセスできなくなる (OSが保証)

f:id:meech:20170121053222p:plain

この「ラッピング」は現在のAndroidでは, LinuxFUSEという機能を使って実装されています. FUSEとはユーザランドで, Linuxファイルシステムを実装するための機能です. 基本的にLinuxファイルシステムは, カーネルの中で実装されていますが, カーネル内でのプログラムは, C言語しか使えなかったり, デバッグが困難であったりと嫌な点が多くあります(でも, めっちゃ楽しいけどね!). ユーザランドファイルシステムを実装できれば, お好きな言語で, 様々なライブラリを活用して, おもしろいファイルシステムを作ることができる, というわけです. 有名なものでは, sshを使ってリモートのファイルにアクセスするsshfs, WindowsのNTFSファイルシステムの読み書きを可能にするntfs3gなどがあります.

さらに, FUSEを使ってLinuxの通常ファイルシステム上で大文字・小文字を区別しないファイルアクセスを実現することもできます. すると, "/sdcard"の「中身」が本当にSDカード(VFAT)であっても, 内部フラッシュ(ext4など)であっても, 上記2つの問題, 大文字・小文字を区別しないアプリの互換性と, アクセス権限の設定を解決することができます.

sdcardfs: FUSEからの脱出

これで話はめでたしめでたし…で終わらず, ここからが本題です.

FUSEを使うことで, アプリからはこれまで通りにファイルアクセスするだけで, ファイルシステムを拡張することができます. ここで通常のファイルアクセスと, FUSE上のファイルアクセスとを比較してみましょう.

通常のファイルシステムのケースを見てみましょう. アプリのファイルアクセスは, まずVFSにハンドルされます. VFSExt4など, そのディレクトリを担当するファイルシステムのコードを呼びだします.

一方FUSEでは, アプリがファイルにアクセスすると, その呼び出しがVFSを通ってFUSEドライバに行きます. ここでアプリがアクセスしようとしたファイルの情報が, カーネルからユーザランドFUSEプログラムに伝えられます. FUSEプログラムを受け取った情報をもとに, ssh先からファイルを取ってくるなどして, その情報をカーネルに送りかえします. カーネルは受け取った結果を, もとのアプリに渡してファイルアクセスが完了します.

ここでFUSEが入っていることで, 一度カーネルからユーザランドに戻っていることがわかります. 今回のような既存のファイルシステムをラップしている場合には, FUSE以外は完全に元のままで, FUSEの部分が純粋にオーバヘッドとなっています.

f:id:meech:20170121044423p:plain

実際のところ, そのオーバヘッドはどの程度でしょうか. すでに一年前にこのAndroidFUSE問題について言及している以下のブログを見てみましょう.

fixbugfix.blogspot.jp

この記事中の実験では,

  • 大きなファイル(700MB弱)のコピーで, FUSEExt4に対して, およそ17%書きこみ速度が低下
  • 大量の小さなファイル(5KB x 10000個, 全約50MB)のコピーに, ext4では17秒. FUSEでは1分以上かかる

という結果が出ています. ここで, 合計サイズの小さなファイル群の方が時間がかかっているのは, ファイルアクセス数, すなわちFUSEドライバがFUSEプログラムを呼びだす回数が小さなファイルコピーの方が多くなるためです.

さらに, さきほどのブログでは, Ext4側とFUSE側とで二重にファイルキャッシュが作られ, メモリを無駄に消費する問題と, FUSEの実装がタイムスタンプの更新がうまくできない問題などが指摘されています.

さあ, ここで本命SDCardFSの登場です. FUSEを使ってラップを作ってみたが遅いし, うまくカーネルの機能と協調できない. じゃあどうするか? カーネルの中に入れればいいんだ.

もう説明もほぼいらないですね. SDCardFSの正体は, これまでFUSEを使いユーザランドで実装されていた「ファイルシステムのラッピング」をカーネルに持っていったものです. VFATとの互換性を保ち, アクセス権限を動的に付与する機能を, パフォーマンスを抑え, カーネルとの協調性を保って実装したものです.

f:id:meech:20170121044510p:plain

VFAT Ext4/F2FS FUSE SDCardFS
互換性 o x o o
アクセス権限 x o o o
オーバヘッド なし なし 大きい 小さい

結果として, FUSEを使っていたオーバヘッドが小さくなる分だけ性能が向上します. しかしながら, 「SD Card FS」はSDカード専用のファイルシステム, というものではありません. SDカードの特性をうまく使って高速化とか, そういうものではありません. F2FSと比べるとかそういうものではありません. SDカードがいた領域を, あたかもそのままSDカードであったかのように見せる, それを速くしました. そういうものです.

宣伝

ね, ファイルシステムおもしろいですよね. Linuxでは, いろんなファイルシステムが実装されています. そんなファイルシステムたちがどのようなデータ構造で, どのようにデータをディスクに保存しているか気になってきましたよね? ちょうど現在, 発売中のSoftware Design 2017年2月号に「Linuxファイルシステムの教科書」と題して, Ext3, Ext4, XFS, F2FS, Btrfsの実装について特集記事を書きました. ファイルシステムの中身をもっと知りたくなったあなたはぜひ購入してみてください.

参考文献

Androidの"/sdcard"については, 知識がなかったので以下を参考にしています

www.xda-developers.com

Linuxのストレージ・メモリ管理に関する会議の議題として, sdcardfsでやっていることさらにVFSに統合していこうという話が提案されている. case-insensitveな探索ができるようにしようとか, アプリケーションレベルでpermissionのハンドルを行うLSM(Linux Security Module)が実装できないかなどが話されるようだ.

'[LSF/MM TOPIC] Getting rid of Android's FUSE/wrapfs hackery' - MARC

で, おれはコードを読みたいんだ. コードはどこだ

(ここから先は上級向けで飛んでいきます)

よっしゃまかせろ. コードはここだ. 読んでくぞ. (以下ほとんど読む過程のdumpで整理されていない)

fs/sdcardfs - kernel/common.git - Git at Google

まず, ファイルシステムに限らずLinux kernel moduleを読む時の鉄則として"__init"の付いた関数を見つけよう. こいつがmoduleの初期化をする. moduleの初期化で, だいたい大事なデータ構造を作ったりしてるので眺めておくと理解がスムーズに行く.

こいつの場合, main.cのinit_sdcardfs_fsがそれ.

fs/sdcardfs/main.c - kernel/common.git - Git at Google

 err = sdcardfs_init_inode_cache();
    if (err)
        goto out;
    err = sdcardfs_init_dentry_cache();
    if (err)
        goto out;
    err = packagelist_init();
    if (err)
        goto out;
    err = register_filesystem(&sdcardfs_fs_type);

ざっと見ると, 以下の3つのデータ構造が使われてそう. package listってなんだろね.

  • inode cache
  • dentry cache
  • packagelist

ファイルシステムの場合, 次に見ていきたいのは, struct file_operations. こいつらがファイルシステム上のファイルの挙動を決める. (mount処理は, だいたいoptionをなめていろいろ初期化してるだけなので, 頭から読むようなものではない, と思う)

const struct file_operations sdcardfs_main_fops = {
    .llseek     = generic_file_llseek,
    .read       = sdcardfs_read,
    .write      = sdcardfs_write,
    .unlocked_ioctl = sdcardfs_unlocked_ioctl,
#ifdef CONFIG_COMPAT
    .compat_ioctl   = sdcardfs_compat_ioctl,
#endif
    .mmap       = sdcardfs_mmap,
    .open       = sdcardfs_open,
    .flush      = sdcardfs_flush,
    .release    = sdcardfs_file_release,
    .fsync      = sdcardfs_fsync,
    .fasync     = sdcardfs_fasync,
};

/* trimmed directory options */
const struct file_operations sdcardfs_dir_fops = {
    .llseek     = generic_file_llseek,
    .read       = generic_read_dir,
    .iterate    = sdcardfs_readdir,
    .unlocked_ioctl = sdcardfs_unlocked_ioctl,
#ifdef CONFIG_COMPAT
    .compat_ioctl   = sdcardfs_compat_ioctl,
#endif
    .open       = sdcardfs_open,
    .release    = sdcardfs_file_release,
    .flush      = sdcardfs_flush,
    .fsync      = sdcardfs_fsync,
    .fasync     = sdcardfs_fasync,
};

変数名から, それぞれファイルとディレクトリに対してのoperationsだとわかる. case-insensitve searchしてくれるんだよな, という知識で眺めると, .iteratesdcardfs_readdirが気になる.

static int sdcardfs_readdir(struct file *file, struct dir_context *ctx)
{
    int err;
    struct file *lower_file = NULL;
    struct dentry *dentry = file->f_path.dentry;

    lower_file = sdcardfs_lower_file(file);

    lower_file->f_pos = file->f_pos;
    err = iterate_dir(lower_file, ctx);
    file->f_pos = lower_file->f_pos;
    if (err >= 0)        /* copy the atime */
        fsstack_copy_attr_atime(d_inode(dentry),
                    file_inode(lower_file));
    return err;
}

意外と面白いところはない. lower_fileで下位のFSのファイルをとってきて, そいつをiterate_dir()でなめる. atimeを上のディレクトリにcopy upする. それだけっぽい

じゃあ, 多分openだな, ということで, sdcardfs_openに行く.

 if(!check_caller_access_to_name(parent->d_inode, dentry->d_name.name)) {
        printk(KERN_INFO "%s: need to check the caller's gid in packages.list\n"
                         "  dentry: %s, task:%s\n",
                         __func__, dentry->d_name.name, current->comm);
        err = -EACCES;
        goto out_err;
    }

    /* save current_cred and override it */
    OVERRIDE_CRED(sbi, saved_cred);

check_caller_access_to_name()に親ディレクトリと, アクセスしようとしているファイル名を渡してアクセス可能かチェックし, OVERRIDE_CREDで権限を書きかえるという流れだろう.

/* Kernel has already enforced everything we returned through
 * derive_permissions_locked(), so this is used to lock down access
 * even further, such as enforcing that apps hold sdcard_rw. */
int check_caller_access_to_name(struct inode *parent_node, const char* name)
{
    /* Always block security-sensitive files at root */
    if (parent_node && SDCARDFS_I(parent_node)->perm == PERM_ROOT) {
        if (!strcasecmp(name, "autorun.inf")
            || !strcasecmp(name, ".android_secure")
            || !strcasecmp(name, "android_secure")) {
            return 0;
        }
    }

    /* Root always has access; access for any other UIDs should always
     * be controlled through packages.list. */
    if (from_kuid(&init_user_ns, current_fsuid()) == 0) {
        return 1;
    }

    /* No extra permissions to enforce */
    return 1;
}

ところがcheck_caller_access_to_nameはあまり大したことをしていない. "autorun.inf"とかのやばそうなファイルへのアクセスを消り, rootにアクセス権を与え, それ以外は弾いているだけ. ふ〜ん…コメントが気になるけど, 一度OVERRIDE_CREDを見る.

OVERRIDE_CREDは結局以下の関数でstruct credを書きかえる.

const struct cred * override_fsids(struct sdcardfs_sb_info* sbi)
{
    struct cred * cred;
    const struct cred * old_cred;

    cred = prepare_creds();
    if (!cred)
        return NULL;

    cred->fsuid = make_kuid(&init_user_ns, sbi->options.fs_low_uid);
    cred->fsgid = make_kgid(&init_user_ns, sbi->options.fs_low_gid);

    old_cred = override_creds(cred);

    return old_cred;
}

cred->fsuid というのがVFSでのUID, fsgidは言うまでもなくGID. FUSE版の方はファイルのattributeをアプリの所有に書きかえる感じだったのが, kernel版では実行主体のcredentialを書きかえてるのが面白い.

コメントで気になったderive_permissions_locked()を見ていく……と思ったけど, そんな関数はない. 似た名前のget_derive_permissions()というのがあやしい. 多分移植の時にコメント書き変えてないんでしょ. よくある. よくする.

結局get_derived_permission_newにたどりつく. 親ディレクトparentと, アクセスするファイルdentryで呼ばれる. newdentryはrenameの時のため.

void get_derived_permission_new(struct dentry *parent, struct dentry *dentry, struct dentry *newdentry)
{
…
    inherit_derived_state(parent->d_inode, dentry->d_inode);

    /* Derive custom permissions based on parent and current node */
    switch (parent_info->perm) {
        case PERM_INHERIT:
            /* Already inherited above */
            break;
…         
        case PERM_ANDROID_DATA:
        case PERM_ANDROID_OBB:
        case PERM_ANDROID_MEDIA:
            appid = get_appid(sbi->pkgl_id, newdentry->d_name.name);
            if (appid != 0) {
                info->d_uid = multiuser_get_uid(parent_info->userid, appid);
            }
            break;
    }
}

inherit_derived_stateで, 親からなんか引き継ぐ. ほとんどそのままだが, 親がPERM_ANDROID_DATAなどだとなんかしている.

    /* This node is "/Android/data" */
    PERM_ANDROID_DATA,
    /* This node is "/Android/obb" */
    PERM_ANDROID_OBB,
    /* This node is "/Android/media" */
    PERM_ANDROID_MEDIA,

なるほどね〜, "/Android/data"とかの直下のファイルだった場合ね. この時, ファイル名から"appid"をとってきて, それをinfo_uidに設定している. multiuser_get_uidは, Androidのマルチユーザ対応っぽい. ここでアプリ個別のディレクトリの所有者が記録されるのかな.

inherit_derived_state()に行く

static void inherit_derived_state(struct inode *parent, struct inode *child)
{
    struct sdcardfs_inode_info *pi = SDCARDFS_I(parent);
    struct sdcardfs_inode_info *ci = SDCARDFS_I(child);

    ci->perm = PERM_INHERIT;
    ci->userid = pi->userid;
    ci->d_uid = pi->d_uid;
    ci->under_android = pi->under_android;
}

いかにもsdcardfs専用構造っぽいstruct sdcardfs_inode_infoが出てきた. SDCARDFS_Iは, struct inode*からstruct sdcardfs_inode_info*に変換するマクロだろ. FS, だいたいこんな書き方する.

permPERM_INHERIT, userdid, d_uid, under_androidは上から引き継ぎ. すなわち, こいつの下もこいつの親からの情報をひきついでいくことになる. それっぽい.

ここまでは, struct sdcardfs_inode_info しかいじられていない. これではアクセス制御になってないな.

get_derived_permissionの呼びだしあたりがあやしいのでgrepする.

struct dentry *sdcardfs_lookup(struct inode *dir, struct dentry *dentry,
                 unsigned int flags)
{
…
    /* save current_cred and override it */
    OVERRIDE_CRED_PTR(SDCARDFS_SB(dir->i_sb), saved_cred);
…
    ret = __sdcardfs_lookup(dentry, flags, &lower_parent_path, SDCARDFS_I(dir)->userid);
    if (IS_ERR(ret))
    {
        goto out;
    }
    if (ret)
        dentry = ret;
    if (dentry->d_inode) {
        fsstack_copy_attr_times(dentry->d_inode,
                    sdcardfs_lower_inode(dentry->d_inode));
        /* get drived permission */
        mutex_lock(&dentry->d_inode->i_mutex);
        get_derived_permission(parent, dentry);
        fix_derived_permission(dentry->d_inode);
        mutex_unlock(&dentry->d_inode->i_mutex);
    }

ここでもcredを変えて, __sdcardfs_lookupして, attributeとかをcopy upして, get_derived_permissionしてる. fix_derived_permissionかなあ

#define fix_derived_permission(x)    \
    do {                        \
        (x)->i_uid = make_kuid(&init_user_ns, SDCARDFS_I(x)->d_uid);  \
        (x)->i_gid = make_kgid(&init_user_ns, get_gid(SDCARDFS_I(x)));   \
        (x)->i_mode = ((x)->i_mode & S_IFMT) | get_mode(SDCARDFS_I(x));\
    } while (0)

あぁ〜確かに, inodeのuidとかgidが, struct sdcardfs_inode_infoに入ってたものに書きかえられてる. さっき, こっちではcredを書きかえるのか〜と思ったけれど, あれはlower FSを読む権限を獲得してるだけで, やっぱりファイルの所有情報書き変えてんのね.

アクセス権限のとこはわかったけど, case-insensitiveのとこはどうなってんだろ. やっぱdentry.cかな.

const struct dentry_operations sdcardfs_ci_dops = {
    .d_revalidate   = sdcardfs_d_revalidate,
    .d_release  = sdcardfs_d_release,
    .d_hash     = sdcardfs_hash_ci,
    .d_compare  = sdcardfs_cmp_ci,
    .d_canonical_path = sdcardfs_canonical_path,
};

専用の dentry_operationsがある. .d_compare = sdcardfs_cmp_ci とかそれっぽい.

static int sdcardfs_cmp_ci(const struct dentry *parent,
        const struct dentry *dentry,
        unsigned int len, const char *str, const struct qstr *name)
{
    if (name->len == len) {
        if (strncasecmp(name->name, str, len) == 0)
            return 0;
    }
    return 1;
}

なるほど見たまんま.

最後に, get_appidを見ておくか…

appid_t get_appid(void *pkgl_id, const char *app_name)
{
    struct packagelist_data *pkgl_dat = pkgl_data_all;
    struct hashtable_entry *hash_cur;
    unsigned int hash = str_hash(app_name);
    appid_t ret_id;

    mutex_lock(&pkgl_dat->hashtable_lock);
    hash_for_each_possible(pkgl_dat->package_to_appid, hash_cur, hlist, hash) {
        if (!strcasecmp(app_name, hash_cur->key)) {
            ret_id = (appid_t)hash_cur->value;
            mutex_unlock(&pkgl_dat->hashtable_lock);
            return ret_id;
        }
    }
    mutex_unlock(&pkgl_dat->hashtable_lock);
    return 0;
}

まあそりゃhashtableひくだけだよね. tableはpackage_to_appidってやつ. insert_str_to_int_lock()が追加している.

このpackagelist.cを見ているとどうやらconfigfsを使ってアプリ名->appidのマッピングが入っているっぽい.

static struct configfs_subsystem sdcardfs_packages_subsys = {
    .su_group = {
        .cg_item = {
            .ci_namebuf = "sdcardfs",
            .ci_type = &sdcardfs_packages_type,
        },
    },
};

static int configfs_sdcardfs_init(void)
{
    int ret;
    struct configfs_subsystem *subsys = &sdcardfs_packages_subsys;

    config_group_init(&subsys->su_group);
    mutex_init(&subsys->su_mutex);
    ret = configfs_register_subsystem(subsys);

configfs中のrootは"sdcardfs"

static struct configfs_group_operations sdcardfs_packages_group_ops = {
    .make_item  = sdcardfs_packages_make_item,
};

static struct config_item_type sdcardfs_packages_type = {
    .ct_item_ops    = &sdcardfs_packages_item_ops,
    .ct_group_ops   = &sdcardfs_packages_group_ops,
    .ct_attrs   = sdcardfs_packages_attrs,
    .ct_owner   = THIS_MODULE,
};

その中にディレクトリを作ることができる (ct_group_ops から)

static struct configfs_attribute package_appid_attr_add_pid = {
    .ca_owner = THIS_MODULE,
    .ca_name = "appid",
    .ca_mode = S_IRUGO | S_IWUGO,
    .show = package_appid_attr_show,
    .store = package_appid_attr_store,
};

static struct configfs_attribute *package_appid_attrs[] = {
    &package_appid_attr_add_pid,
    NULL,
};

その中に"appid"というファイルがある. ここに読み書きできる.

まとめると, "/sys/kernel/config/sdcardfs/app.name/appid"というファイルに数字を書くと, "app.name"->42といったマッピングがさっきのhashtableに登録される.

てことは, 誰かがユーザランド側でこれをやってくれるんだね. なるほどね.

ここまでコードがんがんはしてないけれど、データ構造がわかる感じになるので, もいちどよろしく.

*1:実際どの程度かわからぬですが, 確かに手元のNexus7にはSDカードスロットがない

Software Design 2017年2月号にファイルシステムの特集記事を書きました

Linuxファイルシステムの教科書」と題して、Software Design 2017年2月号第2特集を書きました。

Ext3, Ext4, XFS, F2FS, Btrfsと主たるFSを一通りおさえて、それぞれのデータ構造、そしてどうやってFSが壊れないように保護しているのかを書いています。

読んでFSに詳しくなろう。

ソフトウェアデザイン 2017年 02 月号 [雑誌]
 

 

Atomのlinter-spellで日本語が指摘されないようにするlinter-spell-cjkを書いた

最近AtomでGoを書いたりなどして、なかなかいいねと思ったので、日本語文書もこのままAtomでいくぞ〜と思ったら、spell checkに使っているlinter-spellが大暴れ。いたるところに下線がひかれ、なにがなんだかわっかんない。

こんな感じよ

https://raw.githubusercontent.com/naota/linter-spell-cjk/master/before.png

 

しかも、何が悪いんだと表示されるtipsを見ても、たとえば「くのがいやでーす」は、英語の辞書にないからだめだよ?ということしか言ってこない。こんなにあちこち線をひかれてもなにもわからん。ぐぐってみると、"spell check pluginを無効にしようね"とかあって、嘘でしょそんな〜っ、英語の部分はきっちりspell checkされたいでしょと思うわけです。

ってことで、日本語とかが指摘されないようにするプラグインlinter-spell-cjkを作った。こんな感じにすっきりしてくれる。これなら"exaciting"ってtypoってたことがわかってしまう。

https://raw.githubusercontent.com/naota/linter-spell-cjk/master/after.png

 

 

とりあえず公開した

 

atom.io

 

画像を見るとわかるように、現状では「Atomを」みたいに英語と日本語をまたがって引かれていた線は消えていない。このへんは将来の課題ということで・・・

 

 

 

しかし、linter-spell側にいろいろ手を入れずにその変更をするのは困難だと思われる。linter-spellは、まずprimary dictionary engineに全文を渡す。primaryは、tokenizeして、spell checkして、スペルミス候補の単語リストを返す。返ってきた単語は、追加辞書がさらにチェックして、「スペルミスではない」とか「追加修正候補はこれだ」とか言ってくる。linter-spell-cjkは、この追加辞書として機能して、渡された単語が全て日本語文字で構成されていたら、「これは辞書にあるOKな単語だ」と返している。

日英交ざった単語が降ってきた場合、1) 英語の部分をとりだす 2) 英語の部分をprimary辞書でcheck 3) 間違ってたら、候補を返す, ということをしたい。(1)はregexでOK。(2)はprimaryの辞書は現状わからんが、English hunspellを呼ぶよ、みたいな感じでよさそう。(3)が問題で、いまのlinter-spellだとrangeを変えられないので「primaryは、ここが単語って言ってきたけど、本当はもっと狭いこの部分が単語で、これが修正候補だよ」ということができない。

ということで、linter-spell側でprimary辞書くれて、rangeを狭めることができるようになるといいなあ。

あと、このpackageでは regexpunicode propertyを使ってて、単純にatomのbabelだと自動でそのへんをtranspileしてくれん(babel pluginが認識されてない?)ので、手でtranspileしてるんだけど、これってなんとかなんないんでしょうか。教えてください、atom packageにくわしい人

 

Gentoo made easy 〜 もしくはパッケージを更新しない自由について 〜

これはGentoo Advent Calendar 12/08分です。日付・・・・?なんのことです?

www.adventar.org

みなさん, emergeしてますか. emergeで困るのは謎のエラーです. たとえば以下のようなものを見たことがありませんか

Total: 35 packages (29 upgrades, 1 downgrade, 5 reinstalls), Size of downloads: 211,908 KiB

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

app-text/hunspell:0

  (app-text/hunspell-1.5.3:0/1.5::gentoo, ebuild scheduled for merge) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

  (app-text/hunspell-1.4.2:0/1.4::gentoo, installed) pulled in by
    >=app-text/hunspell-1.2.1:0/1.4= required by (app-text/enchant-1.6.0:0/0::gentoo, installed)
                             ^^^^^^^
    (and 1 more with the same problem)

NOTE: Use the '--verbose-conflicts' option to display parents omitted above

It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously.  If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously. You may want to try a larger value of
the --backtrack option, such as --backtrack=30, in order to see if
that will solve this conflict automatically.

For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.

これはどのようなことが起きているのでしょうか? なんでemergeはビルドしてくれないのでしょうか.

sub-SLOT dependency

さっきのエラーを解説する前に, sub-SLOT dependencyという機能について見ていきます.

多くのプログラムはライブラリを使用します. すると, そのパッケージはそのライブラリに依存することになります. より詳しく言えば, 「ビルドした時点でのライブラリのABI」に依存することになります.

たとえば, パッケージXがライブリLを使うとして, L-1.0がある状態でXがビルドされると, XはL-1.0のABIに依存することになります. すなわち, ライブラリパッケージLが, L-1.0からL-1.1にアップデートされると, Xの動作は壊れてしまう可能性があります.

この問題の1つの解決策として, preserved-rebuildという機能がGentooでは提供されていました. これはXがL-1.1に対してリビルドされるまで, L-1.0のライブラリを残しておくという機能です.

しかし, この機能はpreserve-rebuild状態になったパッケージがリビルドされるまで, ライブラリが残ってしまいます.

こうした場合に依存関係を「壊して」, パッケージXをリビルドさせる方法はないでしょうか? ひとつの方法として, パッケージXに明示的に"=xxx-yyy/L-1.0"に依存させるという方法があります. すると, L-1.1にバージョンが上がると, Xの依存が壊れるので, 1) Lのバージョンを上げないか, 2) Xをリビルドするかで解決することになります.

だが, しかし, それは, Gentoo ではないんだなあ

Gentooは選択なので, パッケージXをL-1.0に対してビルドするか, L-1.1に対してビルドするかを選択できるべきです.

そこで, sub-SLOT dependencyという機能が導入されています. この機能はGentooのSLOT機能を拡張し, ABIに関する依存関係を記録できるようにしたものです. この機能が特徴的なのは, 依存関係がビルド時に書きこまれる, ということです.

たとえば, パッケージXに"xxx-yyy/L:0="と書くと, ビルド時に"xxx-yyy/L:0/1.0"(/の後はsub-SLOT)があれば, 依存に"xxx-yyy/L:0/1.0"が書きこまれます. 同様にビルド時のパッケージが"xxx-yyy/L:0/1.1"であれば, 依存に"xxx-yyy/L:0/1.1"が書かれます.

なぜemergeが文句を言うのか

それでは, sub-SLOT dependencyが分かったとして, なぜemergeが文句を言うのか見ていきましょう. エラーを再掲すると

app-text/hunspell:0

  (app-text/hunspell-1.5.3:0/1.5::gentoo, ebuild scheduled for merge) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

  (app-text/hunspell-1.4.2:0/1.4::gentoo, installed) pulled in by
    >=app-text/hunspell-1.2.1:0/1.4= required by (app-text/enchant-1.6.0:0/0::gentoo, installed)
                             ^^^^^^^
    (and 1 more with the same problem)

こういうエラーです. なにを言っているのかちゃんと見てみましょう.

ここでは, "app-text/hunspell"が"app-text/hunspell-1.5.3:0/1.5"にupdateしようとしているのに対して, "app-text/enchant-1.6.0"が">=app-text/hunspell-1.2.1:0/1.4="と, hunspellのsub-SLOTに依存しているため, enchantの依存関係が壊れるのでemergeを行なうことができないよ!!と言っています.

Portageは現状, sub-SLOTによるリビルドを自動的に実行しません. これは, ある種パッケージのバージョン固定(ここではhunspell)を守るためと言うことができます.

いや, でも, 実際のところ, わりとどうでもいいこと多いよね. 自動的にやってほしくない?

autoemergeによる解決

っということで, こうしたコンフリクトを見つけて, 自動的に解決するスクリプトを書きました.

ここにあるよ. https://github.com/naota/emerge-wrapper/

この autoemerge スクリプトは, 以上のようなエラーを自動で解決します. しかも, この解決はemergeに"--reinstall-atoms="を自動的に追加して, 指定したatomにマッチするパッケージをrebuildしていいよ〜とPortageに伝えることで, 依存の解決を目指し, emergeの機能に閉じているので, 安心して使うことができます.

では, さきほどのケースではどのように使いどのように動くのか見ていきましょう. 中心となるのは"autoemerge"というスクリプトです. 以下のようにしてautoemergeを動かします. emergeと同じ引数を認識します. (というか, そのままemergeに渡していきます)

$ sudo python3.5 ./autoemerge -uDN -j2 world --keep-going --with-bdeps=y

するとemergeが依存を解決し, 以下のエラーを出します.

dev-lang/ocaml:0

  (dev-lang/ocaml-4.04.0:0/4.04.0::gentoo, ebuild scheduled for merge) pulled in by
    >=dev-lang/ocaml-4.04_beta:=[ocamlopt?] required by (dev-ml/camlp4-4.04_p1:0/4.04_p1::gentoo, ebuild scheduled formerge)
    ^^               ^^^^^^^^^

  (dev-lang/ocaml-4.03.0-r1:0/4.03.0::gentoo, ebuild scheduled for merge) pulled in by
    >=dev-lang/ocaml-3.12:0/4.03.0=[ocamlopt] required by (dev-ml/sexplib-113.33.00:0/113.33.00::gentoo, installed)
                         ^^^^^^^^^^
    (and 4 more with the same problem)

autoemergeはこれを解析して, 以下のようなログを出して, 適宜"--reinstall-atoms==dev-ml/sexplib-113.33.00"などをつけて再度依存関係を解析させます

reinstall (dev-ml/sexplib-113.33.00:0/113.33.00::gentoo, installed) for (dev-lang/ocaml-4.03.0-r1:0/4.03.0::gentoo, ebuild scheduled for merge)
reinstall (dev-ml/ocaml-re-1.7.1:0/1.7.1::gentoo, installed) for (dev-lang/ocaml-4.03.0-r1:0/4.03.0::gentoo, ebuild scheduled for merge)
reinstall (dev-ml/pcre-ocaml-7.2.3:0/7.2.3::gentoo, installed) for (dev-lang/ocaml-4.03.0-r1:0/4.03.0::gentoo, ebuild scheduled for merge)
reinstall (dev-ml/pcre-ocaml-7.2.3:0/7.2.3::gentoo, installed) for (dev-lang/ocaml-4.03.0-r1:0/4.03.0::gentoo, ebuild scheduled for merge)
reinstall (dev-ml/ocaml-re-1.7.1:0/1.7.1::gentoo, installed) for (dev-lang/ocaml-4.03.0-r1:0/4.03.0::gentoo, ebuild scheduled for merge)

この作業は再帰的に実行され, 全ての依存が解決された時点で, exec()システムコールでemergeが実行され, あたかも最初から適切な--reinstall-atomsをつけていたかのように, emergeが実行されます.

その他, emergeによってUSEフラグが更新された時に自動的にdispatch-confを呼びだして, emergeを再実行するなど, 手動でemergeを実行する様々な手間が省略されています.

さあ, みなさんautoemergeを使ってらっく〜にGentooを更新していきましょう. (バグが出たら, 笑って報告してね)

sub-SLOTを認め, ビルドしない自由を持つのがGentooなのだ

この後は特に読まなくていいとこです

そもそも, sub-SLOT dependencyが必要なのは, パッケージに"=xxx-yyy/L-1.0"などと書けないためです. ところがこれは, 世の多くのパッケージマネージャでは問題になりません. なぜでしょうか.

なぜなら, そうしたパッケージマネージャは基本的に, 1つのパッケージに対してひとつのバージョンしか提供せず, パッケージリポジトリが規定するライブラリとアプリケーションとの組み合わせをある種強制する, いわば「帝国主義的パッケージマネージャ」であるからです

だがしかし, そのような帝国主義的パッケージマネージャでは生きてはいけないのだ. たとえばお持ちのプログラムがPerl-5.20に依存すればどうなるか? ほしいパッケージが最新のディストリビューションリポトリにはあるが, そのリポジトリではperl-5.22がふってくるならどうすればいいのか. リポジトリに屈して, Perl-5.20および全てのそこに依存するパッケージを自分でビルドするのか? はたまたお手持ちのスクリプトをがんばってPerl-5.22に対応させ, リポジトリ内の最新のもろもろのパッケージに対応させるのか? どちらかを行わせる, これが帝国主義リポジトリの限界なのだ.

だが, われわれGentooには自由がある. お望みであれば, 好きにperlを5.20に留め, それでいて関係ないパッケージは最新にする, それがGentooの自由だ. 帝国主義リポジトリは打倒されるべきではないか? 立ち上がれ, 市民よ. Gentooの光を世界に広めるのだ.

#自宅サーバの思い出 Advent Calendar 一日目

www.adventar.org

みなさん, 自宅サーバは好きですか. ぼくは好きです. 自宅にサーバある! かっこいい!! うっとりしてファンの音を聞いたりなどしていたものですが…でももう自宅にサーバはないです.

そんな人もまだ自宅にサーバがある人も思い出を書くのが, このAdvent Calendarです. とりあえず自分の自宅サーバ設置時の思い出をてきとーに書きます. ゆったりとした気持ちのカレンダーなので, ざっと読んでください.

最初のサーバの話

中学に入り, 技術家庭の教科書を読んでみてプログラムに感動したぼくは「マイコン部」の門を叩きます. マイコンって言ってるけど, Windows 98の環境でF-BASICやVisual Basicが行われていました.

そんなマイコン部でプログラムを作っていると, HTMLも書きたくなるので書いて自分のホームページを作りました〜とかしました. infoseek的なレンタルスペース使ってた気がする.

さて, 太古の話なのでふぁぼられや多分はてブもないので数を数えるためにはカウンターというものを設置するのが一般的でした. CooooooolでいけてるカウンターCGIを探していると, なぜか"Red Hat"というものを見つけました. これはなんとCGIではなく, Linuxというオペレーティングシステムだったようです.

OSを自分で入れられるの? 無料で!? などに感動し, 余っていたマシンにRed Hatをインストールしました. コマンドは, このへんの本で覚えた. これら, 様々基本的なところが一通りまとまっていてとてもよかった…

 

RedHatLinux逆引き大全500の極意 基本操作編

RedHatLinux逆引き大全500の極意 基本操作編

 

 

Linux逆引き大全500の極意コマンド編

Linux逆引き大全500の極意コマンド編

 

 

あと、この2冊もバイブル. これらでよい下地がついた

 

LinuxサーバHacks―プロが使うテクニック&ツール100選

LinuxサーバHacks―プロが使うテクニック&ツール100選

 

  

Unixパワーツール

Unixパワーツール

 

 

とりあえずApachePerlCGIが動く〜掲示板が動く〜などとしてました. やがてメールサーバもやるぞ〜とかしてましたね. qmail, 立ててたよ. あとドメインとるような金や支払い方法はなかったので, Dynamic DNSなどしてがんばっていた.

その後の話

その後, いろんなディストリビューションがあると聞いたのでいろいろやってみました. Fedora Coreが出て, うおっと思ったり, Vine Linuxにしたらコンソールが日本語でかっちょええやん?と思ったり, Fedoraでも日本語コンソールしたいよと思ったりなどしていました. んで〜これはUniconというパッチをカーネルに当てればよい & userland daemonも必要と…わかったのだけれど, なんかFedoraではうまくいかなかったんですね…

そんな中, 高一の時にイギリスで買ったLinux MagazineにGentooが出てきました. めっちゃかっこいいやんこれと思ったわたしは帰国即Gentooインストール. そして, uniconを試すとするっとぬるっと動く!!! このへんの見通しの良さや扱いの良さにほれこみすっかりGentooラブになりました. いまではわたしがGentoo開発者.

Gentooを入れてからは, PHP変愚のスコア検索サイトを作ったりしてました. elisp.net とかいうやばいドメインをとったのもこのへんか?

自宅サーバの終焉

VPSがやってきました. 終焉です.

確かに自宅サーバの方がまだもう少しスペックは良かった. だけれど, 回線事情とか, 電気あたりのメンテとか, たまに部屋にいる時のファンの音など考えているとVPSが良くなってしまった. それにVPSというものを使ってみたかったのだ…

自宅サーバで動かしていたコンテンツは, まるっとVPSに移された. qmailはやめた. IMAPサーバもやめた. メールはpostfixで転送していくだけにした. さくらVPSはべんりだった.

いまVPSでは, GenTwooというものが主にCPUとメモリをmogmogしている. 一番安いプランでやってるから, とてつもなく限界で時々mysqlがOOMで死ぬ. そろそろプラン上げるかな〜〜〜と思っていたら, Amazonからおもしろいの来ましたね. そっち試してみるかな…

…と, 最後はVPS話になりましたが, 自宅サーバはくすぐるロマンがあってかっこよかった. 自宅でLinuxがずーん!とあるのに心が踊った. 自宅サーバのおかげで, Linuxを覚え, viを覚え, Gentooを覚え, カーネルを覚えた. 自宅サーバへのインストールの中でいろんなファイルシステムを知った. 結局, 自宅サーバに心をくすぐられて踊ってるうちに, Gentoo開発者になり, Linuxカーネルの連載をし, ファイルシステムのpatchを書く人間になった. 自宅サーバは少年の心に極めて輝いていた. その機体は実家のクローゼットの片隅で眠っている.

Emacsの描画がおかしくなってつらかったけどdouble bufferingでサイコーになった

i3wm上でEmacsを使っているんですが、描画がときどきおかしくてつらかったんですよ

具体的には、window sizeが変わっても変わった部分が描画されなかったりした。つまり、たとえば幅が画面の左半分->画面全体、となった時に右半分は描画されず黒くなっていたということがおきていた。

他にもC-vでbufferを一気にスクロールすると上半分だけが更新され、下半分は昔の内容のままだったりした。あとは文字の上下に削した文字のなごりなのか、ちょいちょい線が出ることがあって気持ちわるかった・・・

なにが起きているのかはよくわからなかったが、とりあえずdouble buffering patchを当ててたみたらうまくいくんじゃない?ってことで当ててみた

Buttery Smooth Emacs

patchそのものは25.1には奇麗には当たらないので、NEWSとsrc/Makefile.inを編集する必要があった。結果はこんな感じ。

gist.github.com

Gentooのみんなは、このpatchを/etc/portage/patches/app-editors/emacs-25.1/emacs-double-buffer.patchとかに置いて、emerge -1 emacsするだけで簡単にpatchが当たるね。他の人はがんばってね。

さて、このpatchを当ててみると悩んでた問題がすっきり解決した。描画もどことなくきれいだし、スクロールバーがちかちかしてたのも解消した。double bufferingで彼女もできた。これはもうGentooをインストールしてdouble buffering patchを置いてemarge emacsするしかないですね。