コグノスケ

抗生物質

病院に行くと大抵の場合、何らかの抗生物質が処方されます。昔、おなかを壊したとき（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から転記しておくことにした。大幅に追記。