コグノスケ

抗生物質

病院に行くと大抵の場合、何らかの抗生物質が処方されます。昔、おなかを壊したとき（2010年 2月 1日の日記参照）はホスホマイシンを処方されました。

色々種類があるようなので、ちょっとした興味で調べてみたんですが、思っていたより抗生物質の種類は多かったよ……。

「〜マイシン」という命名が多いです。これは放線菌（Streptomyces 属）が産出する抗菌剤を意味するのだとか。なぜ放線菌が数多の抗生物質を作り出すのか、不思議ですね？

細菌に存在する生命維持の機構も、いくつか種類があるので、万能の抗生物質はありません。理解しているのはこのくらいで、作用原理は書き写してみたものの、詳しい仕組みは知りません。

抗生物質の基本的な戦略

付け焼刃の知識ですが、抗生物質の基本的な戦略は、
「人間には存在せず、細菌にしか存在しない生命維持もしくは増殖機構を妨害する」
当たり前ですよね、人間の生命活動まで妨害したら、細菌と一緒に人間まで死んでしまう（＝副作用）ので、薬として成立しません。

例えば、リボソームは mRNA からたんぱく質を生成する器官です。リボソームの働きを妨害すると生命維持に必要なたんぱく質が作れなくなって、細胞は死んでしまいます。リボソームは真核生物（人間）の細胞にも、原核生物（細菌）の細胞にも存在しますが、大きさと形が異なります。真核生物は 60S, 40S という大きさ、原核生物は 50S, 30S という大きさのサブユニットを持っています（参考: 生命の重要な機構である「リボソーム」 | 株式会社 A&T）。

ですので 50S, 30S のサブユニットだけを妨害するような物質を使えば、細菌のみ攻撃して退治できるという寸法です。賢い戦略ですよね。

しかし世の中はそう単純ではなく、真核生物は細胞内にミトコンドリアを持っています。ミトコンドリアは酸素を使いエネルギーを生成するための、非常に大事な器官です。ミトコンドリアは少々変わった器官で、太古の昔に真核生物の細胞内に共生した細菌（リケッチアに近い種類）が祖先と考えられています。

細菌が先祖のミトコンドリアは、細菌と似たようなリボソームを持っています。そのため抗生物質が間違ってミトコンドリアのリボソームまで攻撃してしまい、人間の具合まで悪くなる（＝抗生物質の副作用）原因となっているそうです。

真核生物の中に原核生物が融合しているなんて、何とも場当たり的でムチャクチャに思えますが、ムチャクチャなのに驚きの精密な機構があったりして、生物って面白いですね。

東京の不思議な水道

東京の水道は他の地域に比べるとちょっと変わっています。

水道のことは「東京都」水道局に連絡しますよね？東京以外、例えば以前住んでいた高槻では「高槻市」水道部に連絡します。「大阪府」ではないのです。

水道法は水道を市町村レベルで管理、運営することを定めています（水道法 第六条の2）。特別区（東京23区）については下記規定があり、東京都が管理するものと定められています。

第四十九条
特別区の存する区域においては、この法律中「市町村」とあるのは、「都」と読み替えるものとする。

しかし東京都は23区以外も、武蔵野市、昭島市、羽村市及び檜原村を除いて「東京都」が全ての市町村の水道を管理します。これはかなり変わった運用形態だと思います。

経緯はリンク先（多摩の水道 | 水道事業紹介 | 東京都水道局 - 多摩水道について）にさらっと書かれています。超人口密集地だと、水道一つとっても苦労が多いんですね……。

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

東京のおいしい水

普段、蛇口から出てくる水道水をグイグイ飲んでいますが、特に味や臭いが気になることはありません。以前、つくばに住んでいた時は水道水から異臭がしていたので、天と地の差です。

どこの水か気になったので、調べていたら、東京都水道局がとても便利なサイトを提供してくれていました（配水系統〜ご家庭の水道水情報 | 水源・水質 | 東京都水道局）。住所を入力すると、配水している浄水場、水質検査の結果を見ることができます。

我が家は大田区の東、つまり羽田空港側です。サイトで調べると三郷浄水場から水が来ているようです。家から 30kmくらい離れてます。埼玉からはるばるお疲れ様です……。

水源は江戸川で、水質の良い川ではありませんが、その分浄水場が頑張っていて（高度浄水設備を備えている）、浄水後の水質はかなり良いようです。

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

広域水道事業

Facebook で都道府県営水道は東京だけではないと教えていただきました。

以前（2019年 6月 7日の日記参照）書いたように、水道は基本的には市町村が運営するものです。市町村で維持が難しくなった水道事業を都道府県が引き取る形になっているせいか、各県ごとに運営形態も提供範囲もバラバラです。

全ての都道府県を全て調べるのは大変なので、人口の多そうな都道府県を中心に水道事業の統合について、調べてみました。

神奈川県: 企業局 水道部経営課

横浜市、川崎市を除く西部ほぼ全域
県営水道の給水区域 - 神奈川県ホームページ

千葉県: 企業局

県営ではなく、市町村がいくつか協力し企業団（※1）を形成
千葉県内の各水道事業体のご案内 / 千葉県

愛知県: 企業庁 水道事業課

県営水道と企業団（※2）の複合で、名古屋市、東部一部地域を除く全域
事業概要（水道用水供給事業） - 愛知県

大阪府: 大阪広域水道企業団（府営水道を引き継いだ）

泉南、北部の一部市町村
大阪府域の水道の広域化について | 大阪広域水道企業団

京都府: 京都府営水道事務所、府民環境部公営企画課

南部の人口密集地
水道事業のあらまし / 京都府ホームページ

東京以外にも色々なところでやっていますね。共通しているのは人口が多い、供給面積が広い、ダムから遠く水源がないなど、1市町村で水道を賄えなくなっていることでしょうか。

今まで住んだことのある市町村は、偶然いずれも広域水道に入っていませんでした。つまり田舎ばかりだったということか……？

※1: 千葉県の水道企業団
九十九里地域水道企業団（匝瑳市、東金市、茂原市、横芝光町、大網白里市、九十九里町、山武市、一宮町、睦沢町、長生村、白子町、長柄町、長南町）
北千葉広域水道企業団（千葉県水道局、松戸市、野田市、柏市、流山市、我孫子市、習志野市、八千代市）
東総広域水道企業団（銚子市、旭市、東庄町）
君津広域水道企業団（千葉県水道局、木更津市、君津市、富津市、袖ケ浦市）
印旛郡市広域市町村圏事務組合水道企業部（成田市、佐倉市、四街道市、酒々井町、八街市、印西市、白井市）
南房総広域水道企業団（館山市、勝浦市、鴨川市、大多喜町、いすみ市、御宿町、鋸南町、南房総市、三芳(企)）

※2: 愛知県の水道企業団
愛知中部水道企業団（豊明市・日進市・みよし市・長久手市・東郷町）
北名古屋水道企業団（北名古屋市・豊山町）、丹羽広域事務組合（大口町・扶桑町）
海部南部水道企業団（愛西市・弥富市・飛島村）

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

GCC を調べる - その 3 - RTL (Register Transfer Language) の出力

目次: GCC を調べる - まとめリンク

GCC の内部情報を出力してみます。GCC のバックエンドは GIMPLE と RTL (Register Transfer Language) があります。

ざっくり言って C 言語（など）→ GIMPLE → RTL → アセンブラの順に変換されます。GIMPLE の内容はまだよく知らないので説明できません……。今回は RTL を見ていこうと思います。

RTL を出力する方法

GCC で RTL を出力するには、コンパイル時に -fdump-rtl-all オプションを付けます。

$ riscv32-unknown-elf-gcc a.c -fdump-rtl-all

試しに下記のコードをコンパイルし、RTL を出力させると、

void main()
{
        int a = 1, b = 2, c;

        c = a + b;

        return c;
}

下記のような RTL が出力されます（GCC-8.3.0 での結果）。C 言語のファイル名が a.c だとすると、RTL は a.c.NNNr.XXXX という名前で出力されます。NNN は最適化パスの番号、XXXX は最適化パスの名前が入ります。

;; Function main (main, funcdef_no=0, decl_uid=1514, cgraph_uid=0, symbol_order=0)

(note 1 0 3 NOTE_INSN_DELETED)
(note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 3 5 2 NOTE_INSN_FUNCTION_BEG)
(insn 5 2 6 2 (set (reg:SI 104)
        (const_int 1 [0x1])) "a.c":3 132 {*movsi_internal}
     (nil))
(insn 6 5 7 2 (set (mem/c:SI (plus:SI (reg/f:SI 65 frame)
                (const_int -4 [0xfffffffffffffffc])) [1 a+0 S4 A32])
        (reg:SI 104)) "a.c":3 132 {*movsi_internal}
     (nil))
(insn 7 6 8 2 (set (reg:SI 105)
        (const_int 2 [0x2])) "a.c":3 132 {*movsi_internal}
     (nil))
(insn 8 7 9 2 (set (mem/c:SI (plus:SI (reg/f:SI 65 frame)
                (const_int -8 [0xfffffffffffffff8])) [1 b+0 S4 A32])
        (reg:SI 105)) "a.c":3 132 {*movsi_internal}
     (nil))
(insn 9 8 10 2 (set (reg:SI 107)
        (mem/c:SI (plus:SI (reg/f:SI 65 frame)
                (const_int -4 [0xfffffffffffffffc])) [1 a+0 S4 A32])) "a.c":5 132 {*movsi_internal}
     (nil))
(insn 10 9 11 2 (set (reg:SI 108)
        (mem/c:SI (plus:SI (reg/f:SI 65 frame)
                (const_int -8 [0xfffffffffffffff8])) [1 b+0 S4 A32])) "a.c":5 132 {*movsi_internal}
     (nil))
(insn 11 10 12 2 (set (reg:SI 106)
        (plus:SI (reg:SI 107)
            (reg:SI 108))) "a.c":5 3 {addsi3}
     (nil))
(insn 12 11 17 2 (set (mem/c:SI (plus:SI (reg/f:SI 65 frame)
                (const_int -12 [0xfffffffffffffff4])) [1 c+0 S4 A32])
        (reg:SI 106)) "a.c":5 132 {*movsi_internal}
     (nil))
(insn 17 12 0 2 (const_int 0 [0]) "a.c":7 240 {nop}
     (nil))

RTL は最適化処理を実行するたびに内容が変わるため、たくさんのファイルが出力されます。上記の RTL は GIMPLE から RTL に変換した後、命令割当のみ行った状態のものです。最適化パス名でいうと vregs というパスが終わった後の RTL です。

長くなってきたので分割します。

GCC を調べる - その 4 - RTL (Register Transfer Language) を眺める

目次: GCC を調べる - まとめリンク

RTL は (演算子 引数1 引数2 ...) という形で表記されます。Lisp の S 式に似ているんですかね？前回（2019年 6月 14日の日記参照）出力した RTL のうち 5番目の insn を例にとります。

(insn 6 5 7 2 (set (mem/c:SI (plus:SI (reg/f:SI 65 frame)
                (const_int -4 [0xfffffffffffffffc])) [1 a+0 S4 A32])
        (reg:SI 104)) "a.c":3 132 {*movsi_internal}
     (nil))

RTL はいくつも種類があり、code という番号で区別されています。RTL をファイルに出力する際は code は名前に変換され、開きカッコの後に書かれます。

先頭の RTL は (insn ... で始まっているので、code = insn の RTL で、その後 (set ... とあるので、code = set の RTL があるんだな、ということがわかります。上記の RTL に出てくる code は、insn, set, mem, plus, reg, const_int の 6種類です。

RTL を読んでみる

RTL は引数を取ります。先程の例に出てくる RTL の引数は rtl.def に定義されています。一例を示すと下記のとおりです。

• insn : uuBeiie
• set : ee
• mem : e0
• plus : ee
• reg : r
• const_int: w

例えば set の ee であれば e という種類の引数を 2つ取る、という意味です。GCC では RTL の引数をこのように定義します。かなり意味不明だと思いますが、こういうものだと思うしかないです。

さらに e という種類の 引数は別の RTL を含んで OK なので、RTL は入れ子になります。先の例に出てきた RTL を分割してみます。

                     ____________________________________________________________________________________________________________________________________  ________  ______________________  _______
                    | e insn__________________________________________________________________________________________________________   ________________ | i insn  | i insn                | e insn
                    |      | e set      __________________________________________________________________________  _  _______________  | e set           |         |                       |
                    |      |           | e mem     ______________________  _______________________________________ |0 | mem additional  |                 |         |                       |
                    |      |           |          | e plus     _________  | e plus      _________________________  |  |                 |          ______ |         |                       |
         __  __  _  |      |           |          |           | r reg     |            | w const_int               |  |                 |         | r reg |         |                       |
        | u | u | B |      |           |          |           |           |            |                           |  |                 |         |       |         |                       |
(insn 6 | 5 | 7 | 2 | (set | (mem/c:SI | (plus:SI | (reg/f:SI | 65 frame) | (const_int | -4 [0xfffffffffffffffc])) |  | [1 a+0 S4 A32]) | (reg:SI | 104)) | "a.c":3 | 132 {*movsi_internal} | (nil))

途切れ目が非常にわかりにくいです。私も正直ぱっと見ではわかりません。特に引数 e は入れ子になっていて、ひたすら見づらいです。RTL の引数の正確な切れ目を知るには、print_rtx_operand_code_e() など、引数の print 関数を見るのが一番早いかもしれません。

RTL の引数の切れ目を見るには

RTL の出力をリアルタイムで見たいときは、gdb で print_rtl_with_bb() 辺りにブレークを掛けておいて、ステップ実行していくとわかりやすいです。

その際 printf 系の出力がバッファリングされると、print した文字列がなかなかファイルに出力されません。デバッグ時は print 文と、実際に出力されている文字列の対応が確認しづらいため、最初に setvbuf() を呼んでバッファリングを無効にしておいたほうが見やすいと思います。

/* Like dump_function_to_file, but for RTL.  Print out dataflow information
   for the start of each basic block.  FLAGS are the TDF_* masks documented
   in dumpfile.h.  */

void
print_rtl_with_bb (FILE *outf, const rtx_insn *rtx_first, dump_flags_t flags)
{
  const rtx_insn *tmp_rtx;

  setvbuf(outf, NULL, _IONBF, 0);  //★★この行を足した★★

  if (rtx_first == 0)
    fprintf (outf, "(nil)\n");
  else
    {
      enum bb_state { NOT_IN_BB, IN_ONE_BB, IN_MULTIPLE_BB };

  //...

あとは観察したい RTL ファイルを tail -f とかで追い続ければ良いでしょう。

やっつけ感が満載の GCC

RTL の名前と引数の情報を定義した rtl.def というファイルがあるのですが、これだけを見るといかにも整然としたルールに則っているように見えます。ですが実際は例外だらけで、コードを読んでいるとなかなか辛いものがあります……。

例えば、今回の例で行くと mem の最後に何か（[1 a+0 S4 A32] というやつ）出力されていますよね？rtl.def を見ると mem の引数の定義は "e0" なので、"0" の一部だろうと考えたくなりますが、残念ながら、この情報については rtl.def には一切記述がありません。これはひどい。

RTL を文字列として出力する print_rtx() 関数の実装を見ると、最後の方で MEM, CONST_DOUBLE, CONST_WIDE_INT, CONST_POLY_INT, CODE_LABEL だけ特別扱いして、特別に出力が追加されます。16進数だと見づらいし、とりあえず出しておこうという感じでしょうか……。

ノート PC の充電器（代打）

以前、出張先にノート PC のアダプタ（USB-PD）を忘れて帰ってきてしまったことがあります。

我が家のノート PC の電源端子は USB Type-C なので、試しにスマホ用の充電器を繋いでみたのですが、うんともすんとも言いませんでした。ノート PC など USB-PD で充電する機器は、充電器側も USB-PD に対応していないと充電が開始されないみたいです。

次のミスに備えて、普段使いの充電器＋ノート PC アダプタの代打、が可能な AUKEY の USB-PD 充電器 PA-Y12（AUKEY PA-Y12 のサイト）を買いました。Amazon で 5,000円くらいです。

大きさは手のひらサイズくらいですね。端子は Type-C + Type-A x 2 の 3ポートで、出力は合計 72W（Type-C: USB-PD 20V 3A, Type-A: 5V 2.4A）ですから、大抵の USB-PD 機器には対応できるはずです。

普段はスマホ（USB type-C）と Kindle の充電にしか使っていないので、若干勿体ない感が否めないですが、備えあれば憂いなし。

購入は先月（5/25）で、使用して 1か月ほど経っていますが、特に異音や異常もなく元気に動いくれています。良い感じです。

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

ROCK64 の音が linux-next で鳴らなくなった

目次: ROCK64/ROCKPro64 - まとめリンク

ある時から linux-next で ROCK64 の PCM デバイスが全部消えて、一切音が鳴らなくなっていました。ROCKPro64 も同じようです。

結論だけ先に言うと、この問題は既に ALSA ML で指摘されていて、下記のコミットをリバートすると直ります。

commit b9f2e25c599bbbf0646957e07ebb72b942c286cc
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date:   Thu Jun 20 09:49:33 2019 +0900

    ASoC: soc-core: use soc_find_component() at snd_soc_find_dai()

    snd_soc_find_dai() finds component first via specified
    snd_soc_dai_link_component, and find DAI from it.

    We already have soc_find_component() to find component,
    but soc_find_dai() has original implementation to find component.

    We shouldn't have duplicate implementation to do same things.
    This patch uses soc_find_component() at soc_find_dai()

    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>

これは散々調べた後で知りました。悲しい。せっかくなので調べたこともメモしておきます。

ASoC とコンポーネントの登録

最近、ALSA SoC Layer（以下、ASoC）は、ルネサスの森本さんという方の尽力により、実装がかなり変わっているのですが、その一部がバグっていたようです。

ASoC は大まかにいうと、登録と組み合わせの 2段階に分かれています。

ドライバの probe 時に、2つの component を登録します。正式な呼び名がわからないので、ここではとりあえず PCM と DMAC の component と呼びます。

PCM component は DAI（Digital Audio Interface）を持っています。DAI は PCM データの入出力インタフェースのことらしいです。他にも CODEC と呼ばれる、PCM データ（デジタル音声）←→ アナログ音声に変換するドライバも component として扱われています。

サウンドカードのドライバは、複数の component を組み合わせて、PCM の入出力やアナログ音声出力などを実現する仕組みです。

もう少しコード寄りに説明すると PCM component は devm_snd_soc_register_component() を使い、DMAC component は devm_snd_dmaengine_pcm_register() を使って登録します。

これらの関数を呼び出すと、

devm_snd_soc_register_component()
  snd_soc_register_component()
    snd_soc_add_component()
      snd_soc_register_dais()
        soc_add_dai()          ★DAI を component に登録★
      snd_soc_component_add()
        list_add(&component->list, &component_list); ★component をリストに登録★

devm_snd_dmaengine_pcm_register()
  snd_dmaengine_pcm_register()
    snd_soc_add_component()
      snd_soc_component_add()
        list_add(&component->list, &component_list); ★component をリストに登録★

このような経路を辿ります。

一方、component を組み合わせる際は、

devm_snd_soc_register_card()
  snd_soc_register_card()
    snd_soc_bind_card()
      snd_soc_instantiate_card()
        soc_bind_dai_link()
          snd_soc_find_dai()
            soc_find_component() ★最近変更された部分、適切な component を探す、しかし…★

このように処理されます。

問題の箇所

前置きがかなり長くなりましたが、上記の処理のうち snd_soc_find_dai() の変更にバグがあるようです。元々は関数内に component を探す処理が記述されていましたが、処理は削除され soc_find_component() で適切なコンポーネントを探してくる、という実装に変わりました。

先ほど説明した通り、大抵の ASoC ドライバは PCM 用の component を devm_snd_soc_register_component() で、DMAC 用のコンポーネントを devm_snd_dmaengine_pcm_register() で登録しますが、かなり残念なことに双方とも全く同じ名前で登録されてしまいます。

例えば ROCKPro64 で /sys/kernel/debug/asoc/components を見ると、

root@rockpro64:/# cat /sys/kernel/debug/asoc/components
hdmi-audio-codec.3.auto
ff870000.spdif
ff870000.spdif
ff8a0000.i2s
ff8a0000.i2s
ff890000.i2s
ff890000.i2s
ff880000.i2s
ff880000.i2s
spdif-dit
snd-soc-dummy

このように、同じ名前の component が 2つ登録されていることがわかります。今回のバグの件をさておいても、名前が重複しているのはイマイチですよね……。

組み合わせる際は devm_snd_soc_register_component() で登録した方、つまり PCM 用の component（こいつが DAI を持っている）を探してこなければ、PCM デバイスは正常に登録されません。

しかし soc_find_component() は動きがおかしくて、devm_snd_dmaengine_pcm_register() で登録した方のコンポーネントを返してしまいます。

結果、DAI が見つけることができず、エラーになってしまい、1つもサウンドカードが登録されないままドライバの登録処理が終わります。

もう少し早く知りたかった

この問題を散々調べた後で、既に ALSA ML にて指摘されていたことを知りました。

ALSA ML を最初に調べれば、こんなにコード解析しなくても良かったなあ、と思う一方で、そもそもどういうバグかわからないと、メールは探せないので、鶏と卵ですね。

それと、今に始まったことではありませんが、ASoC は似たような名前の関数が多くて混乱します。先ほど説明にも出ましたが、snd_soc_add_component() と snd_soc_component_add() なんて、一見で違いがわかりません。何でこんな変な名前にしたんだろう……。

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