won't fix

HiFive Premier P550を手に入れた

2025-01-12T15:38:00.003+09:00

SiFive P550というコア使ったHiFive Premiver P550というボードを入手した。メモリ16GBが日本円で約60000円強。前買ったUnmatchedはドルだと$250高かったけど、円的にはそんなに変わらず。円安...

Install Ubuntu to SSD

確かまだPremier P550対応のDTSなどLinuxのコードはメインラインには入ってないけど、eMMCにはUbuntu 24.04 TLSがプレインストールされていてシリアルコンソール経由でログインすることが出来るが、SATAポートがこのボードに存在しているので、SSDにインストールすることにする

イメージを取得

https://github.com/sifive/hifive-premier-p550-ubuntu/releases/tag/2024.11.00にUbuntuのイメージが置かれているので、これを入手する

ディスクに書き込む

まずxzで圧縮されているので、展開

xz -d ubuntu-24.04-preinstalled-server-riscv64.img.xz

SSDが/dev/sdaだとして、ddコマンドでディスクに書き込む

dd if=ubuntu-24.04-preinstalled-server-riscv64.img of=/dev/sda bs=1M

この状態でリブートするとSSDが(hd0)になるので、SSD経由でブートする。ただし、eMMCはこのイメージを書き込んであるっぽいので、GPTのUUIDが全部一緒になるので、好みにおおじてGPTを変えてupdate-grubかけたほうがよい

Unix Bench

------------------------------------------------------------------------
Benchmark Run: Sun Jan 12 2025 06:34:27 - 07:02:47
4 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       12927124.9 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     2641.1 MWIPS (9.9 s, 7 samples)
Execl Throughput                               1176.6 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        229490.7 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           72809.9 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        374429.0 KBps  (30.0 s, 2 samples)
Pipe Throughput                              475331.9 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  31965.9 lps   (10.0 s, 7 samples)
Process Creation                               2703.0 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   3510.5 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   1154.5 lpm   (60.0 s, 2 samples)
System Call Overhead                         590916.1 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   12927124.9   1107.7
Double-Precision Whetstone                       55.0       2641.1    480.2
Execl Throughput                                 43.0       1176.6    273.6
File Copy 1024 bufsize 2000 maxblocks          3960.0     229490.7    579.5
File Copy 256 bufsize 500 maxblocks            1655.0      72809.9    439.9
File Copy 4096 bufsize 8000 maxblocks          5800.0     374429.0    645.6
Pipe Throughput                               12440.0     475331.9    382.1
Pipe-based Context Switching                   4000.0      31965.9     79.9
Process Creation                                126.0       2703.0    214.5
Shell Scripts (1 concurrent)                     42.4       3510.5    828.0
Shell Scripts (8 concurrent)                      6.0       1154.5   1924.2
System Call Overhead                          15000.0     590916.1    393.9
                                                                   ========
System Benchmarks Index Score                                         463.6

------------------------------------------------------------------------
Benchmark Run: Sun Jan 12 2025 07:02:47 - 07:31:09
4 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables       51689178.8 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                    10560.7 MWIPS (9.9 s, 7 samples)
Execl Throughput                               4324.4 lps   (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        758792.3 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          282576.0 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       1383510.8 KBps  (30.0 s, 2 samples)
Pipe Throughput                             1893625.3 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 218013.6 lps   (10.0 s, 7 samples)
Process Creation                               9020.4 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   9097.3 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   1184.8 lpm   (60.1 s, 2 samples)
System Call Overhead                        2362850.1 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   51689178.8   4429.2
Double-Precision Whetstone                       55.0      10560.7   1920.1
Execl Throughput                                 43.0       4324.4   1005.7
File Copy 1024 bufsize 2000 maxblocks          3960.0     758792.3   1916.1
File Copy 256 bufsize 500 maxblocks            1655.0     282576.0   1707.4
File Copy 4096 bufsize 8000 maxblocks          5800.0    1383510.8   2385.4
Pipe Throughput                               12440.0    1893625.3   1522.2
Pipe-based Context Switching                   4000.0     218013.6    545.0
Process Creation                                126.0       9020.4    715.9
Shell Scripts (1 concurrent)                     42.4       9097.3   2145.6
Shell Scripts (8 concurrent)                      6.0       1184.8   1974.6
System Call Overhead                          15000.0    2362850.1   1575.2
                                                                   ========
System Benchmarks Index Score                                        1591.8

大体Unmatchedの2倍くらいの速度

2024年に買ったもの

2025-01-10T16:37:00.004+09:00

買ったものを書いているけど、これ以外には、家 (賃貸) のトレイが壊れたため、結果として新しいトイレのユニットに入れ替わった (元のトイレは25年前のもの)。今どきトイレは水の使用量が少なくなっていたりするけど、そもそもシャワートイレにしないところが、大家...とは思ったが

Google Pixel 8a

これをメイン機にして、いままで使っていたPixel 6aをテスト機に格下げしました。前までの手頃値段感はなくなったけど継続して買っている。個人的にPixel買っている理由は、Androidのアップデートが長期的に行われそうなところ、aシリーズであれば手頃な値段に落ち着いていることと、万一画面が割れたとしても、iCrackedで当日持ち帰りの修理が可能なところ (Googleでの修理扱いになる) なだけで、これを満たしているのであればどれでもいいんだが

Panasonic 食器洗い乾燥機 SOLOTA NP-TML1

5月に購入。食洗機があると生活が変わるという記事を見たりするのだけど、ふと買ってしまった。確かに便利だし、寝る前に洗い忘れて、朝マグカップを洗うなんてことは日常だったので、生活はより楽にはなった。ただこの食洗機のレビューにいつも書いてあることだけど、これが受け入れられるかどうかで評価が変わる

洗浄、乾燥で合計2時間かかる
大きさが用途に合わないと、使い物にならない

ただ台数は売れないだろうから、ずっと同じものを5年以上売るんだろうね (Panasonicのロボット掃除機みたく)

象印オーブンレンジ EVERINO ES-GW26

10月に購入。元々持っていたオーブンレンジ (三菱電機製) は20年以上使っていたしまったく壊れる気配がなかったのだが、新しいものが欲しくなって購入。今どきの電子レンジってこんなに機能豊富なんだなと改めて感動。スチームオーブンと迷ったけど、十分満足

デロンギコーヒーグラインダー KG79J

12月に購入。コーヒー自体はドルチェグストを使っているのだけど、種類に飽きてきてコーヒー豆を買ってきたくなったのでミルを購入。価格も手頃だし、機能自体は挽く粗さを選べたり満足なのだが掃除が超面倒。メンテンス性が悪いという評判は見てたのだけど、これがね...

RISC-VにおけるCrypto命令 (Crypto Extension)

2025-01-07T02:00:00.028+09:00

やっとこさVector Extensionも1.0になり、そろそろいろんなExtensionを実装したSoCも出てくるとは思うけど、年末の移動時間のなかでいろいろ現在のCrypto Extensionを勉強してた

Crypto ExtensioもScalar命令版とVector命令版の２つがあって、Scalar版は組み込みとか用途向けの、レジスタとかを増やしたくない実装用で、Vectorはその名の通りVectorレジスタを使ったもの。試しにAESのEncryptionを実装してみる

Scalar版

Scalar版は以下のようになる。

void
riscv64zkn_aes_encrypt_block_128(uint64_t* expandedKey,
                                 uint8_t *output,
                                 const uint8_t *input)
{
  uint64_t state0 = *((uint64_t *)input);
  uint64_t state1 = *((uint64_t *)(input + 8));

  // Add round key 0 to initial state
  state0 = state0 ^ *expandedKey++;
  state1 = state1 ^ *expandedKey++;

  for (int i = 1; i < 10; r++) {
    uint64_t c0 = __riscv_aes64esm(state0, state1);
    uint64_t c1 = __riscv_aes64esm(state1, state0);
    state0 = c0 ^ *expandedKey++;
    state1 = c1 ^ *expandedKey++;
  }

  // Final round
  uint64_t c0 = __riscv_aes64es(state0, state1);
  uint64_t c1 = __riscv_aes64es(state1, state0);
  state0 = c0 ^ *expandedKey++;
  state1 = c1 ^ *expandedKey;

  *((uint64_t *)output) = state0;
  *((uint64_t *)(output + 8)) = state1;
}

Vector版

Vector版。まだVector Crypto ExtensionのIntrinics命令はStableじゃないので、インラインアセンブラ使ってる。

static vuint32m4_t
vaesz_vs(vuint32m4_t rd, vuint32m4_t vs2)
{
  __asm__("vaesz.vs %0, %1" : "+vr"(rd) : "vr"(vs2));
  return rd;
}

static vuint32m4_t
vaesem_vs(vuint32m4_t rd, vuint32m4_t vs2)
{
  __asm__("vaesem.vs %0, %1" : "+vr"(rd) : "vr"(vs2));
  return rd;
}

static vuint32m4_t
vaesef_vs(vuint32m4_t rd, vuint32m4_t vs2)
{
  __asm__("vaesef.vs %0, %1" : "+vr"(rd) : "vr"(vs2));
  return rd;
}

SECStatus
riscv64zvkn_aes_encrypt_block_128(uint32_t* expandedKey,
                                  uint8_t *output,
                                  const uint8_t *input)
{
  size_t vl = __riscv_vsetvl_e32m4(4);
  vuint32m4_t state = __riscv_vle32_v_u32m4((const uint32_t *)input, vl);

  // Add round key 0 to initial state
  vuint32m4_t K = __riscv_vle32_v_u32m4(expandedKey, vl);
  expandedKey += 4;
  state = vaesz_vs(state, K);

  for (int i = 1; i < 10; r++) {
    K = __riscv_vle32_v_u32m4(expandedKey, vl);
    expandedKey += 4;
    state = vaesem_vs(state, K);
  }

  // Final round
  K = __riscv_vle32_v_u32m4(expandedKey, vl);
  state = vaesef_vs(state, K);
  __riscv_vse32_v_u32m4((uint32_t *)output, state, vl);
}

Conclusion

RISC-Vの場合Load/Restoreをまとめないとvlenの長さを指定するvsetvliが大量に利用することになるので、速さに直結するかもということと、コンパイラ (gcc、LLVM) の最適化もまだまだっぽい
両方ともx86のAES-NIに似た感じなので、AES-NIの経験値があれば、難しくないかも

So-net 光 with フレッツS から別会社の光コラボ回線への転用が地雷すぎる

2024-09-27T16:02:00.008+09:00

自分のオープンソースへのコントリビューションする際のメアドのドメインはずっとso-net.ne.jpなのだが (もちろん別にドメイン持ってるし、それを使ったメアドもある) 、いろいろ思うこともあり、自宅の回線をSo-netではない回線に変えることにした

そもそもフレッツ使っているのは2020年ころまでADSL使ってのもあって、NTTから工事手数料無料でフレッツ光に切り替えるキャンペーンを使ったからってのが一番の理由なのだが

当然のことながらPPoEだと遅いときがたまにあるので、IPoEオプションを使っているのだが、別の光コラボ回線に切り替えるにあたって、解約する必要があるようなので、先にSo-net側のIPv6オプションをWeb上で解約した (はずだった)

解約したのに関わらず、解約申込み中のままになっており、数日待てど一切ステータスが変化しない

おそらく月末処理にしているか、間違えて解約する人向けに数日待つ仕様にしているのだろうが、こっちとしては、光コラボ回線への切り替えの日付が決まっているので、即時解約されないと困る

そのため、サポートに問い合わせると、初めの担当者は「転用の日にコース変更とIPv6オプションの解約をWebからすれば問題ない」と回答してきたのだが、どうも転用という作業がどういうことがたぶんわかってないようだ

いろんな情報を集めると、転用元のIPoEが解約されていないと転用先でIPoEが使えないため、下手すると転用の契約自体がキャンセルされるなりして、両方つかえなくなることも起きるらしい

安全に行くなら切り替えの前の日にはIPoEが解約されていたほうがいい感じなので、もう一度サポートに問い合わせた

サポートに「いつ解約になるのかを教えて欲しい。転用が控えているのですぐ解約できないと困る」と伝えたところ、サポート経由だと即時解約が可能らしく、その担当者経由で即時解約してもらった

Webページでのオプション変更では解決できず、サポートにチャットをしないと (So-netは電話サポートは別契約が必要)、解決しないだなんて、地雷だよな

なお、Googleで検索した際に表示されるこれもウソ。こっちは1週間待ったけど、解約申込み中にままだった

2024/9/28追記

1日経って、転用当日 (というよりも転用先の工事予定時間すぎ) に接続を見てみたところ、転用先のIPoEでつながっておらず、従来のフレッツのままということが判明

以前説明してもらったようにIPoEが未だに使えているという状態 = 転用に失敗しているということで、しょうがなくSo-netにまたチャットサポートを投げてみたところ、「エラーが発生してて、解約処理ができてない」ということがやっとわかった

サポートの人に苦言するのは申し訳ないけれど、ちゃんとした社内の技術担当がフレッツ側にチケット投げて作業すればいいはずの話のようにしか聞こえないのに、サポートの人はうちではいつできるのかわからないの一点張りでこの問題の解決する道筋がでないので、積んだ状態。ホント困った。このせいで来月も料金発生するのかと思うと、So-netはISPとしてひどい有様になったんんだなぁと残念な気持ちになった。はぁ

あと別会社の光コラボ回線への転用は、その転用元にとってはユーザーが逃げるということでもあり、そういうところのサポートを対応したくないという気持ちはわかるのだが、出てくるサポートの人が不正確な情報をユーザーに説明するのはどうかと思う

最初の人は切り替わってからコース変更で問題ない (v6オプションのことは触れない) と言っていたり、切り替えにあたってFAQなりWebのセルフサポートで済むようにすれば、ユーザー側は無駄なコストをかけなくてすむし、サポートへの問い合わせというコストを払う必要もないわけだ

So-netはNuro光で良い話を聞かないけど、なるほどなーと思える対応でした。まだ終わってないけどな

Android 14 (Credential Manager) におけるパスキー対応が面倒すぎる

2024-08-01T16:20:00.004+09:00

DroidKaigiにココらへんの話をしようと思って、CfP書いたけど落ちたので、自分用の覚書。

Firefox (GeckoView) AndroidでCredentail Managerの対応を入れたのが、GeckoViewとしてはバイナリサイズを大きくしたくないため、JetPackを一切使わずにCredential Manager経由でWebAuthn対応を行うコードをJavaでスクラッチで書いた。おそらくJavaでスクラッチで書いたのはChromeとGeckoViewだけだし、おそらくこの2つの製品以外でスクラッチ実装がされることは今後もないと思う。

しかもGeckoViewはWebブラウザエンジンなわけだから、いろんなWebサイトで実行可能な必要がある (= オリジンを正確に設定する必要がある)。この値を設定するのもおそらくBlinkとGeckoの2つの製品以外でほぼ存在しないであろう。なので、実装にあたって、実装者、すなわち自分しか被害者がいない事例がいろいろあることになるわけだ。自分はGoogleの人じゃないので、社内情報アクセスできないからね。

従来の実装方法

Google Mobile Service (GMS) にFIDO API (https://developers.google.com/android/reference/com/google/android/gms/fido/fido2/package-summary)が提供されていた。これを使うことでWebAuthnの実装が簡単にできるようになっている。またとあるバージョン以降であればパスキーをGoogle Password Managerに登録することが可能。これは古いAndroidでも動作する。

Credential Managerとは

Andorid 14から Credential Managerという仕組みが追加された。このCredential Managerはサービスとして実装されるもので、サードパーティに対して認証要求を移譲できる。ただこのサービスには3つのメソッドしか存在しなくて、登録・認証・削除があるだけだ。幅広い認証情報を扱えるようにAndroidチームの人は考えためであろうけど、この3つのメソッドには引数がBundleしか実質存在しない。すなわちアプリケーションはBundleに各々好き勝手に情報を入れると、OSにインストールされたCredential Managerサービスたちが、登録成功とか返すようになっている。なおBundleに何入れるべきか？なんてものも存在しない

Credential Managerを使ったパスキー実装

パスキーを実装するには、このBundleになにかを入れる必要があるのだが、そんな情報はdeveloper.android.comには一切存在しない。GeckoViewでは一通りのBundle定義をしているが、これらはJetPackのコードとChromeのコードから持ってきている。オープンソースだったからいいようなものだが、これらの謎定義はGoogle社内でしか共有されていないような感じなので、まぁなんというかEU頑張れって感じ。ここには入れていないが、Google Password Managerだけ無視するっぽく見える定義もあったりする

実際問題、JetPackを使った場合はここらのBundle問題はJetPack側で吸収されるので、そこらは問題になりえないのだが、問題はリクエスト用のJSONは自分たちで組み立てないといけないってことだ。なので、WebAuthnの仕様をちゃんと理解しないといけない。それをアプリケーション開発者に求めるのはどうかと思う。なおレスポンスもJSONむき出しで渡される。検証とかしたい場合は、むき出しで渡されたJSONデータを展開して検証しないといけない。

以前のGMSのFIDO APIではJSONむき出しな仕組みにはなっていない。引数はBuilderが用意されているので、必要なパラメータを設定するだけで行える。ちなみにGeckoViewでいうと、これがCredential Manager版でここがFIDO API版なのだが、Credential Manager版は自分でJSONを組み立てるのに対して、FIDO API版はBuilderで引数を組み立てる。

あと、検証時 (Assertion) には落とし穴が実は存在してて、クライアントサイドで検証する際には、レスポンスのJSONの ClientDataJsonハッシュを使って検証を行うわけだけど、レスポンス内のこの値は正しくない可能性があって、リクエスト時にBundleに入れたClientDataJsonのハッシュが正しい値だったりする (これは2日悩んだ)

現在のCredential Managerがどの認証方法を対応しているか?

そんな方法はない。

とりあえず試してみて、サービスがTYPE_NO_CREATE_OPTIONSを返してくれれば、たぶん対応していないということがわかる。なお、1Passwordは最初のリクエストでサービス自体がクラッシュしたりするので正しく動かなかったりする。GeckoViewだと登録時はResident KeyがRequiredのときだけCrednetial Managerを使うようにしているが、Preferredの場合にどうするかは決めかねている。

また、認証を行おうとしてるクレデンシャルがGoogle Password Managerで認証可能かどうか？みたいなのはFIDO API経由で確認は可能なので、認証可能であればGMSのFIDO2 APIを使って、認証できない場合は Credential Managerを使ういうこともできる。GeckoViewもChromeもそのようなコードを入れている。

結論

GMSのFIDO APIがCredential Manager対応すれば、みんなハッピーだったのでは?やっとサードパーティ製品で対応が増えてきたところだしさ

Firefox Androidにおけるresident key (Discoverable Credentials) 対応

2023-05-11T17:41:00.004+09:00

これの続き

Firefox AndroidにおいてはWebAuthnの実装をGoogleの FIDO2ライブラリを使っている。このライブラリはWebAuthn APIをそのままJavaのインターフェイスにしたようなものなので、Firefox AndroidにおけるWebAuthnの対応はこのライブラリの実装内容に依存している。

今年になってこのライブラリがアップデートされ、resident key (Discoverable Credentials) 対応が含まれた。ただ残念?なことにそのAPIを使うと、CredentialsがGoogle Password Managerで他のデバイスとGoogleアカウントを通じて同期するようになる。要は勝手にPasskey対応になってしまう。もちろん同期しないオプションなんてアプリケーション側が使えるAPIには存在しない。なお、デバイスがGoogleアカウントにサインインしてない場合、Passkeyが作成できないというエラーでWebAuthn APIは失敗する。

このような状況なので、いくつか懸念点はあるんだが、Firefox AndroidのStable版はabout:configを使えるわけではないので、デフォルトオフで実装は入れておいた。Firefox 114のBetaおよびNightlyでabout:configで該当設定を変更すれば使えるようになる。

PasskeysがGoogleアカウント経由で同期されるということは、例えば、ChromeでPasskeyを使ってサインインした場合、そこで利用されたCredentialがFirefoxでも使えてしまう (もちろん逆も同じ)。そのような感じでいろいろどうかと思う動作がいろいろあるので、Bug 1831137に解決しないといけない問題は書いてある。個人的にはAndroid 14以上の場合だけ使えるようにしてもいいかもだけど、まだ最終的な結論は決めてない。なぜAndroid 14以降なのかというと、このバージョンではCredential Provier Serviceというものが導入される予定で、Autofill Serviceのようにシステム側で使うように設定しておけば、Google Passowrd Managerではなく、設定したサードパーティのサービスが使える予定らしい。Android 14が出てから考えよう

MacBook Air (2020) M1のUSB-Cポートが壊れたのでApple Storeで交換 (修理) した

2023-04-22T08:24:00.003+09:00

最近、ビデオ会議のときはMacBook Airを使っている。理由は自宅で使っているDebian/sidな環境でスピーカーフォンが使えたり使えなかったりと不安定だからなのだが (これはpipewireに変わってから頻発してるので、どうにか原因は突き止めたいと思っている)、ミーティングの時間にMacBook Airを使おうとしたら、電源が入らなくなっている。USB-Cポートが一つ壊れていたのだが、こっちのポートも壊れたか、マザーボード自体壊れたっぽい。新しいものを買うという選択肢もあるのだけど、すぐ直ったらラッキーなので、Apple Storeに修理の予約を入れた。

Apple Storeで現象の説明 (電源が入らない) を説明した後、USB-Cポートも一つ壊れているので、両方壊れているのかもしれないという話をしたところ、一回中身見ますね、ってことで自分のMacBook Airをバックヤードに持っていって、分解して調査をしてもらった。

その後、すぐ戻ってきて、

壊れたUSB-Cポートは、どうもゴムらしきものが挟まっていて、それが原因っぽい
今まで使えてたUSB-Cポートは洗浄してみてどうなるかを調べる

という話になり、作業した後にチェックすると、今まで使えてたUSB-Cポートはちゃんと動作する (= 充電が開始され、電源が入る) ようになり、もう一つの前から壊れてたポートは、動かなかったり動いたりと不安定な状態だった。「このままでもいいですけど、ボード交換という修理も可能です。交換の場合は15000円強になります」という説明を受けて、それだったら修理にするということで修理に出した。値段の大部分は作業料で、実際のボード部分は2000円らしい

修理に出したのが夕方で翌日の夕方には修理完了ということで、Apple Storeでピックアップ可能になってた。一日でピックアップできるのは非常に満足だった。昔東芝が秋葉原のサービスセンター持ってた時に、運が良くてすぐピックアップ可能だったのだけど、販売元が修理の際にちゃんと説明してくれるのは非常に満足度高いよねと

How to build Firefox for Linux/riscv64 on Ubuntu 22.10 + Unmatched

2023-03-24T12:32:00.012+09:00

A people asks me about how to build Firefox/riscv64. Since all patches to build it are merged, so the instruction is updated from previous. The following instruction is on Ubuntu 22.10 on riscv64gc

Clone firefox code from mozilla official repository
- hg clone https://hg.mozilla.org/mozilla-central (Mercurial)
- git clone https://github.com/mozilla/gecko-dev (git).
Change current directory to cloned directory
- cd mozilla-central (if using mercurial)
- cd gecko-dev (if using git)

Create mozconfig file in current dicrectory. File content is the following

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir
mk_add_options AUTOCLOBBER=1

ac_add_options --enable-application=browser
ac_add_options --disable-debug
ac_add_options --enable-optimize
ac_add_options --disable-tests
ac_add_options --without-wasm-sandboxed-libraries

Install rust. See rustup.rs
Install clang and nodejs
- sudo apt install clang nodejs
Run ./mach bootstrap and select "2. Firefox for Desktop"
Run ./mach configure
Run ./mach build. It spends 8-9 hours.

Enjoy!

Google Mobile ServiceのFIDOパッケージを使うと勝手にPasskey対応になる

2023-03-22T10:47:00.008+09:00

Google Mobile Service (GMS) にFIDOのパッケージがあるんだが、今年リリースされたVersion 19でWebAuthnにおけるDiscoverable Credentials (Resident key)の対応ができるAPIが追加されている。

Blinkを使っていないとあるWeb BrowserのAndroid版におけるWebAuthn対応はこのGMSのパッケージを使っているおかげで、Resident keyの対応をしていなかったのだが、このパッケージのバージョンにアップデートすれば解決するかも？と考えて、手元で修正コードを書いてみたんだけど、以下のように表示されて勝手にPasskey対応になるっぽい。

上記のように勝手にPasskey対応になってしまい、しかもGoogleアカウント内に同期されちゃうから、とあるWeb Browserの事情だと実装するには、いろんな人たちの許可取らないといけないので、Resident key対応は一時中断することにした。個人的にはPasskeyを使うかどうかのオプションが欲しいのだけどないっぽいし、あの検索会社自体の都合でそれをつけてくれるのはないだろうな、しかもこのパッケージ、GMSだし。

Pixel 6aの画面が割れたのでiCrackedで修理した

2023-03-16T13:37:00.001+09:00

仕事でスマホOSの開発、デバイスリリースもやったし、今もスマホOS向けのWebブラウザ作ってる仕事をしてるわけだが、なんでもスマホに取り込むということはなおさら信用できない。今回旅先でPixel 6aを落として画面を割ったときも、ガラス面が割れるだけだと良かったのだけど、パネルごと割れてしまって、画面が映らなくなった。そんな状態になったら、画面を確認することはできないわけだから、飛行機のチケットとか (QRコード)、電子マネーのチャージとかもできないわけで。そもそも落とす自分が悪いわけだけど、スマホにすべて取り込むというのは正直ないなと改めて思う。

そんな話はさておき、自分が所有しているアメリカン・エクスプレスではスマホの盗難・故障に対する保証制度 (スマートフォン・プロテクション) というものがあり、修理金額の一部を補填してくれるので、それを行った。そのときのお話。

まず、この保証制度を申し込むためには、以下のものが必要になる

そのスマートフォンを買った際の領収書。Pixelの場合はGoogleから買った際に送られてくるメールで問題なし
故障を証明する写真。今回は画面が割れている本体の画像
修理内容、代金を証明する書類。今回の場合はiCrackedで修理を行ったので、その作業が書かれた書類。修理されたときに渡される

今回の修理はiCrackedで行った。ここはGoogleの正規サービスプロバイダなので、ここで修理しても本体保証は変わらないらしい。店舗自体が都内にはいくつもあるのでネットで申し込んで空いていれば当日に修理を行ってもらえる。修理時間も1時間もかからないので、郵送よりも実店舗に直接行くのが便利だと思う。

なお、AMEXのスマートフォン・プロテクション、申込みから実質2営業日くらいでお金が振り込まれるので、非常に便利でした。でもGoogleはUSでやっているPreferred Careを日本で展開できないのはなんでだろう。売れてないんだろうな

Oliveに移行しようとしたら、利用可能な口座がありませんと言われる

2023-03-07T19:33:00.006+09:00

親への生活費とか家賃の振り込みを毎月行う必要があり、銀行自体も各々で違うので振り込み手数料をできる限り安くする方法をいろいろとっていたのだが、三井住友銀行 (SMBC) でOliveというサービスが始まり、手数料を下げられそうだったので、移行することにした。

アプリをインストールして、SMBC IDというアカウントを作り、早速口座を移行しようとしたら、"Oliveアカウントに切替可能な口座がありません" というエラーが起きた。Oliveアカウントの切替診断から辿れるFAQを見ても、不可能条件に合致しておらず、SMBC Directから口座の種類を見ても "残高別金利型普通預金" なので、全く理由がわからない。しいてあげれば、この口座はさくら銀行時代に作ったものをずっと使っている。キャッシュカードもSMBCに変更してるし、なにか内部で変な契約になっているしか思えない。

悩んでも仕方ないので、SMBCのチャットサポートで問い合わせようにしても、混雑してて問い合わせできないので、SMBC Direct経由でメールで問い合わせた。

一日後、返事があり、どうも自分の口座は「カードローン（総合口座型）」というものなっているらしく (検索してもほぼ情報が存在しない)、カードローン口座の契約を止めればOliveへの切替可能とのことで家の近くの支店でカードローン口座を止めてきた。銀行の受付で説明しても「？？？」な顔をされたので、これに合致する人はすくないのではと思う。

なんで、こんな契約になってかをいろいろ思い出してみると、心当たりがあって、口座を作った時に「給料振り込み口座にしていただければ、10万円まで口座残高がマイナスになっても可能」というようなものを契約した覚えがたしかにあり (あの頃は新卒社会人でいろいろ借金あった)、それが銀行が変わってくにつれ、最終的に「カードローン（総合口座型）」という契約になったんだろうと推測される。ただ、SMBC Directやアプリで見ても "残高別金利型普通預金" としか表示されないので、わかるはずないよねと。

利用可能な口座がありませんと言われる人は、SMBC Directのメール問い合わせで聞くといいと思う。結果として実店舗行くことになると思うけど

なお補足だが、銀行に問い合わせた時、切替不可能な条件に以下があったのは笑った。そりゃそうか。

* 口座名義に銀行のシステム上反映することのできない漢字が含まれる場合

2022年に買ったもの

2023-01-06T22:16:00.002+09:00

今年は書く内容のあるものを買ってないなぁと思いながら。

clockwork DevTerm R1

ここにすでに書いてあるが、補足。

キーボードがしょぼくて、ゆっくりじゃないと入力がほぼ不可能。結果としてUSBキーボード差さないと使い物にならない。
ローエンドの阿里巴巴のチップ、GPUがまともに入ってないので、表示に関してはただ表示できるレベルの遅さ

初めてRISC-V64デバイス買うのであればいいけど、SiFiveのボード持ってるから、まぁ触らなくなっちゃった

Logicool LIFT

MX Verticalユーザーだったのだけど、トラッキングが調子悪くなってきて (今までのLogicool製品では経験なかった)、買い替えるデバイスをどれにしようか考えてるときに発売になったので。サイズ感はこっちのほうが好みなので、買ってよかった。

Google Pixel 6a

前まで使ってたPixel 4aの画面を割ってしまったので。Pixel 4aのAndroidのバージョンも13で打ち止めだし、14へ向けてのデバイスが欲しかったので購入。充電時とかに無駄に熱くなるとかちょっと重いとか、Pixel 4aに比べると出来がいいとは思わなないけど、しょうがないよね。

なお、画面を割ったPixel 4aは、東急ハンズに入ってる iCracked (Googleの正規修理業者) に持ち込んで画面を交換してもらいました。1時間30分くらいで交換終了して約2万円ほど。壊してもいい検証機に格下げ。

Firefox for macOS版をLinux上でビルドする

2022-12-06T15:30:00.001+09:00

自分用メモ

Firefoxのビルド環境はカスタムビルドされたclangを使っているため、Linux上でmacOS版のビルドができたりする。実際AWS/GCP上のTaskCluster (MozillaのCI) ではmacOS版はLinuxでクロスビルドしてる。問題はSDKのヘッダとかなんだが、まぁここらからもってくるなり別のmacOS環境からSDKのヘッダ・ライブラリ一式を持ってこればどうにかなる。

mozconfigファイルはこんな感じでいけるはず

mk_add_options MACOS_SDK_DIR=/other/MacOS-SDKs/MacOSX11.3.sdk
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-macos

ac_add_options --target=x86_64-apple-darwin
ac_add_options --enable-debug
ac_add_options --enable-optimize
ac_add_options --enable-tests
ac_add_options --with-macos-sdk=/other/MacOS-SDKs/MacOSX11.3.sdk

RISC-VなClockwork DevTermがやってきた

2022-06-02T21:12:00.007+09:00

Clockworkが発売してるDevTermにRISC-V64なボードが追加されてたので買ったところ届きました。

中のパーツは組み立てる必要がある。電源はUSB-C経由だが、18650バッテリー搭載可能。

なお、このボードは阿里巴巴のXuanTie C906コアなAllwinner D1使っているのでこんな感じ。

cpi@devterm-R01:~$ uname -a
Linux devterm-R01 5.4.61 #12 PREEMPT Wed Mar 30 14:44:22 CST 2022 riscv64 riscv64 riscv64 GNU/Linux

cpi@devterm-R01:~$ cat /proc/cpuinfo
processor	: 0
hart		: 0
isa		: rv64imafdcvu
mmu		: sv39

だそうです。Vecter Extension!

同梱のSDカードにUbuntu 22.04ベースの起動イメージが入っているのだが、これはhttp://dl.clockworkpi.com/からダウンロード可能。なお、スクラッチから作る方法も公開されている

なお、参考にUnix Bench

========================================================================
   BYTE UNIX Benchmarks (Version 5.1.3)

   System: devterm-R01: GNU/Linux
   OS: GNU/Linux -- 5.4.61 -- #12 PREEMPT Wed Mar 30 14:44:22 CST 2022
   Machine: riscv64 (riscv64)
   Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
   16:18:46 up 3 min,  2 users,  load average: 0.92, 1.11, 0.53; runlevel 2022-06-02

------------------------------------------------------------------------
Benchmark Run: Fri Jun 03 2022 16:18:46 - 16:46:57
1 CPU in system; running 1 parallel copy of tests

Dhrystone 2 using register variables        2958013.9 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     1045.0 MWIPS (9.9 s, 7 samples)
Execl Throughput                                254.0 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks         44255.0 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           12537.2 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        116663.8 KBps  (30.0 s, 2 samples)
Pipe Throughput                              163270.2 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  26226.4 lps   (10.0 s, 7 samples)
Process Creation                                696.3 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                    567.4 lpm   (60.1 s, 2 samples)
Shell Scripts (8 concurrent)                     73.9 lpm   (60.5 s, 2 samples)
System Call Overhead                         383377.8 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0    2958013.9    253.5
Double-Precision Whetstone                       55.0       1045.0    190.0
Execl Throughput                                 43.0        254.0     59.1
File Copy 1024 bufsize 2000 maxblocks          3960.0      44255.0    111.8
File Copy 256 bufsize 500 maxblocks            1655.0      12537.2     75.8
File Copy 4096 bufsize 8000 maxblocks          5800.0     116663.8    201.1
Pipe Throughput                               12440.0     163270.2    131.2
Pipe-based Context Switching                   4000.0      26226.4     65.6
Process Creation                                126.0        696.3     55.3
Shell Scripts (1 concurrent)                     42.4        567.4    133.8
Shell Scripts (8 concurrent)                      6.0         73.9    123.1
System Call Overhead                          15000.0     383377.8    255.6
                                                                   ========
System Benchmarks Index Score                                         120.8

Intl.MessageFormat

2022-05-24T20:42:00.002+09:00

hi18n (i18nライブラリ) の紹介 (1) 設計思想と基本方針というのを見た。このブログ記事を見るとこれは文字列翻訳のメッセージフォーマットを行うライブラリの話らしい。翻訳というのは、Localizaiton (L10N) と呼ぶもので、Internationalization (i18n) とは違う。i18nというのは、文字翻訳じゃなくて、多言語を扱う、表示するということを基本指す。例えば日本語が表示できるとか入力ができるとか。まずwantedly社は正しい言葉を使うようにしてほしい。

さて、本題。

こういうメッセージフォーマットというのは、どうもいろいろ各社持っているらしく、車輪の再発明を各社でやっている状況らしい。そんな状態は労働力の無駄でしかないので、ECMA-402でIntl.MessageFormatというのを作ることになった。元のベースはFirefoxで使っているFluentと呼んでいるライブラリで、そもそもそれはFirefox OSのときに作られた仕組み (今は某社で働いてるZibiがFirefox OSのころからやってて、これをFirefox本体へ持ち込むときにECMA-402のいろんな仕様も追加してた)。

Intl.MessageFormatはただのAPIだけど、メッセージフォーマットの仕様はThe MessageFormat 2.0 Specificationに現時点のドラフトがある。ICU4Xで使えればWASMでも使えるので、自社で同じような機能の車輪の再発明を行っているのであれば、ここでいろいろ意見を言えば取り込まれると思うよ

2021年に買ったもの

2021-12-31T11:12:00.032+09:00

Google Pixel 4a

XPERIA XZ2 Compactを使っていたのだが、3度目の修理になったタイミングでメイン端末の代わりとして購入。XPERIA XZシリーズはほんと出来が悪かったし、ドコモ経由で買ってたので、修理代が非常に安く、あれでは元を取れてないのではと思うものだった。

Googleはこのくらいのミッドレンジの端末が一番コスパいいと思うので続けてほしいと思う。そもそも昔のNexusのときと違ってAOSPそのままではなくなってるし、どれがリファレンスなんだかわからなくなってはいるが。

HiFive Unmatched

2020年にオーダーしたものだったけど、5月くらいに到着。Mini-ITXなケースと電源、AMDのPCIeなGPUを用意すると、普通にLinuxが実用速度でボートするRISC-Vボードなので、いろんなコードを試しにポートしてみた。今年くらいにリリースされるようなSoCだと今度はSIMDとかCrypto Extensionとか実装されてそうし、新しいSoCが入ったボードが出たら買うだろうな。

TP-Link 5ポート 2.5Gbps ハブアンマネージスイッチングハブ TL-SG105-M2

コスパはいいTP-Linkが最安クラスの2.5Gbpsハブを発売したので、早速購入。結構熱は持つけど、速度としては安定してる。そういえば、自分が100Mbpsなハブを買ったのもこのくらいの値段になったころだったなぁと思い出した。

SwitchBotスマート加湿器

部屋が乾燥してて朝起きると喉の調子がわるいので、購入。加湿器を買うんだったらくだらないものを買おうと思い、SwitchBotにした。はっきりいうと加湿器なんてずっとつけっぱなしだし、タンクの水がなくなっているという情報をスマホで見ても、だから？って感じなので、スマホとかからコントロールするような機能は改めていらないなと。

ネスカフェドルチェグスト MINI ME

家でコーヒーの飲む時は一杯毎ドリップして飲んでいたのだけど、面倒になって、コストコでMINI MEを購入。自分のような面倒くさがりな人にとってはこういうカプセルのものが理にかなってた。

山善エアフライヤー YAF-C120

普通の電気フライヤーは持ってはいるのだけど、油の処理がもったいない気がしてて、エアフライヤーで代替できないかと思って購入。はっきりいうと中途半端過ぎて、代替にならなかった。200℃だと微妙に温度が足りない感。たしかにフライドポテトとかは簡単にできるのだけど、その程度かなぁ。今後も使い続けるかは微妙。

Web Speech APIのSpeechSynthesisEvent.elapsedTimeは秒を返すのだけど

2021-11-30T10:19:00.005+09:00

バグレポートを受け取って気づいたのだけど、SpeechSynthesisEvent.elapsedTimeは秒を返すのが正しい。ただほとんどのブラウザがこの値を秒で返していなかった (例外はFirefox for Linuxくらいかも)。なので、Safariも最近直っていたので、Firefox側も直した。

ここまでは普通の話なのだが、バグ報告をした人がChromeでも同じ問題が起きるとしてバグを報告したのだが、このバグが滑稽。Chromeはバグを受け付けるとQAが出てくるのだけど、そのQAがまずWeb APIの仕様を理解してないし、理解しようともしない。その人を乗り越えないと、Bug Triageさえちゃんとやってくれないようで、バグを認識させるためにはそのQAが投げ出すまで付き合ってあげないといけなくて、非常に無駄なコストがかかる。google.comじゃなくてchromium.orgのメアドを使っているからどこかのベンダーなんだと予想してるのだけど、そうだったらもっとまともな会社使おうよと、Google。

そもそもWeb Platform test (wpt) でTest failure発生させられる話だったら、そういうテストケースを書いておいて、さくっとwptに入れちゃうのだけど、このissueに関してはwptを書きようがないので、まぁChromeチームはずっと放置すると読んでる。

なお、Bug Triageに関してはMozillaは詳しい人かチームマネージャがやるので、大概ちゃんとした人が見ることになることが多い。こんな感じでBug Triageをちゃんとやらない製品はバグ修正とかにコストかけない (または評価システム上、評価されない) だろうなぁと勝手に思ってる。

いまさらながらAndroidのAutofill Frameworkの困った話

2021-10-08T23:37:00.004+09:00

AndroidのAutofillというのは、カスタムコントロールを使わないアプリにとっては実装は難しくはないのだが、カスタムビューを実装しているアプリでは、自分でいろいろな情報を提供しないといけない。実際には、自動入力用にアプリを最適化するに書かれているように、システムがAutofill用の情報を要求してきたら提供する、フォーカスの状態をシステムに通知するなどを追加実装する必要がある。

全部のアプリケーションでそのような実装しているとは限らないので、実装していないような昔のアプリケーション用にAndroidはおせっかいな機能を追加している。互換モードだ。これはアクセシビリティの実装を用いたautofillのエミュレーションを提供するもので、カスタムビューがアクセシビリティ機能の実装をしている場合は、それを利用してAutofill情報を設定する。そもそもアクセシビリティの実装しててAutofillの実装しないアプリがあるのかと問い詰めたいところではあるが。

この互換モードというのは自動的に切り替わるわけではなくて、Autofillサービス側で事前に設定をする。だから例えばアプリがAutofillの実装を入れたとしても、アプリ側からこの互換モードを無効にする方法は残念ながらない。この互換モードが動作してしまうと、アクセシビリティノードの走査が走ってしまうため、当然ながらパフォーマンス問題を引き起こす。アクセシビリティノードの走査はandroid.view.Viewの実装内で行われているから、該当コードを実行しないようにすれば、アクセシビリティノードの走査が実行されなくなるので、ある程度は回避可能ではある。残念ながらある程度ね。

この互換モードで実行しているかどうかは、こんな感じで調べられると思う。

public boolean isCompatibilityMode(Context context) {
  try {
    final AccessibilityManager manager =
      (AccessibilityManager) context.getSystemService(
                               Context.ACCESSIBILITY_SERVICE);
    if (manager == null) {
      return false;
    }
    final List<AccessibilityServiceInfo> serviceInfoList =
      manager.getEnabledAccessibilityServiceList(0);
    if (serviceInfoList == null) {
      return false;
    }
    for (final AccessibilityServiceInfo info : serviceInfoList) {
      if (info.getId().equals(
        "android/com.android.server.autofill.AutofillCompatAccessibilityService"
      )) {
        return true;
      }
    }
  } catch (final Exception e) {
  }
  return false;
}

アクセシビリティノードを走査させないようにしたとしても、互換モードは引き続きおせっかいなコードを実行する。この互換モードが動作する際には、CompatibilityBridgeと呼ばれるものがアクセシビリティイベントをウォッチするようになる (これについては無効にする方法はない)。そのためアクセシビリティイベントを発火させるとそれに応じて勝手にAutofillの互換コードが実行されてしまう。例えばAccessibilityEvent.TYPE_VIEW_FOCUSEDのイベントを受け取ると、AutofillManager.notifyViewEnteredを呼び指したりする。そのため内部でAutofillフォーカスがアクセシビリティノード上に移動する。たとえアプリケーションがAutofill情報を提供してたとしてもだ。AndroidのAutofillはフォーカスが移った際にAutofill用のリクエストをAutofillサービスに渡すので、互換モードでかつ、もしアプリがAutofillの実装をしてた場合、2度リクエストが飛ぶという困ったことになってる。

今どきのWebブラウザというにはOSのAPIはUI Processで実行される。Webコンテンツ内のアクセシビリティ情報をコンテンツのロード時にContent Processで集められ、集まった後UI Processへ送られる。アクセシビリティ情報の収集というのは非常に重い処理なので、UI Processへ送られるのは、ブラウザにとっては相当後になる。なので下手をするとAutofillフォーカスが予期もしてないアクセシビリティノードに奪われた状態でAutofillサービスがAutofillのUIを出したりしようとするので、ブラウザにとっては予期しない動作になりがちになる。例えば、Bug 1693152とかBug 1715549とか。

このように残念な互換モードを使っているAutofillサービスで有名なのはBitwarden。昔Bitwardenの開発者になんで互換モードに設定しているの？って聞いたけどよくわからない答えを返してきたので、今度こそどうにか止めさせるつもり。このような問題に引っかかるのはたぶん自分だけだと思いたいし、Androidはこの互換モードをアプリ側から止める方法を提供してほしかった。

なお、Bitwardenを使ってて、たまにChromeとかでもAutofillが動かないという話があれば、おそらくこのパターンの話。

OSのIME関連APIとWebブラウザは相性が悪い

2021-09-02T19:56:00.002+09:00

今どきのWebブラウザは複数のプロセスで動くことが前提になっている。Chromeで言えば、メイン(UI)プロセスとレンダラープロセス。Firefox用語であればChromeプロセスとコンテンツプロセスという感じで別れて動作している。Webコンテンツはコンテンツ用のプロセスで表示され、文字入力はUI用プロセスで動作している。だから入力された文字はコンテンツ用のプロセスへプロセス間通信で送られ、コンテンツ用プロセスで内部的に描画されるいることになる (実際に画面上に描画されるのがGPUプロセスだったりUIプロセスだったりするけど)。

今どきのOSで使われるIMEのためのAPIは入力された文字をただアプリケーションに渡すだけではなく、様々なことを要求してくる。例えば文字変換の精度を上げるために現在入力している場所周辺の文字情報をアプリケーションへ要求したり、文字変換用パネルウィンドウの表示位置を決定するために、アプリケーションが文字入力している表示座標の問い合わせをアプリケーションへ行ったりする。

Webブラウザは反応速度を上げるため、基本的にはブロッキングするようなプロセス間通信を許可しない (もちろん例外がないわけではないが)。プロセス間通信は基本的に非同期で行われてる。たとえば、コンテンツ用プロセスがビジーな状況というのは結構ありがちな状況で、その状況下で同期モデルなプロセス間通信を使うと、当然のことながら、そのプロセス間通信が正常終了するまでに長い時間がかかり、反応速度が非常に悪くなる。なので基本的には非同期なプロセス間通信を利用している。

この非同期なプロセス間通信のみを許可するというところが、非常にIME関連APIとの相性を悪くしている。なぜなら多くのケースでこれらのAPIが非同期API (例えば引数で渡されたコールバック関数経由で値を渡す) ではなくて、同期APIになってたりする。または、非同期的なレスポンス (エラーコードとして、今はPendingだからまた問い合わせてねというものを返す) を返すことが可能であっても、そのエラーコードを見てくれなかったりなど、まぁWebブラウザがこういうモデルを要求しているというニーズにIME関連APIがマッチしてない。APIデザインが最後発であるAndroidでさえ、残念ながらここらがすべて非同期になってない。

そんなこと言っていても、OS側がこちらの欲しいAPIを実装してくれるわけでもないので、ChromeもFirefoxもいろんな手を使ってこの状況下でもIMEを動かすようにしている。ただうまく行かないケースになった場合、例えばIMEの候補ウィンドウが間違った場所に表示されてしまったりするのは、これらのブラウザ側のハックがうまく動かなかったケースになる。Android版になると、メインプロセス内でもブラウザのメインスレッドとAndroidのUIスレッドが別になるので、より複雑さを増したりする。

なお、Apple (macOS) はWebKit2のときにこの問題を解決するめに非公開の非同期API群を作って対処した。Appleズルい

Firefox on Linux/riscv64

2021-07-02T15:27:00.009+09:00

This step is out of date since I have merged all patches to trunk. Please read How to build Firefox for Linux/riscv64 on Ubuntu 22.10 + Unmatched instead.

Although I don't land all patches to mozilla-central yet, source code is https://github.com/makotokato/gecko-dev/tree/riscv64.

To build this, you have to build nodejs v16.0 since Firefox build sytem requires it. So I recommend that you setup cross compile environemnt instead of building on Unmatched board host.

Also, this is .mozconfig sample.

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir
mk_add_options AUTOCLOBBER=1
ac_add_options NODEJS=/home/makoto/node-v16/bin/node

ac_add_options --enable-application=browser
ac_add_options --disable-debug
ac_add_options --enable-optimize

export CC=gcc
export CXX=g++

If using corss compile,

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir
mk_add_options AUTOCLOBBER=1

ac_add_options --enable-application=browser
ac_add_options --disable-debug
ac_add_options --enable-optimize

ac_add_options --target=riscv64
export CC=riscv64-linux-gnu-gcc
export CXX=riscv64-linux-gnu-g++
export HOST_CC=gcc
export HOST_CXX=g++

HiFive Unmatched にUbuntuをインストールする

2021-06-07T16:22:00.006+09:00

デフォルトのSDカードには、OpenEmbededな環境のLinuxがインストールされているのだが、いろいろパッケージをアップデートしたいので、NVMeを取り付けて、そこにUbuntuをインストールした。

Install Ubuntu on HiFive Unmatchedに方法が書いてあるのだが、この方法だと実はブートしない。

u-boot-update

した後、

/boot/extlinux/extlinux.confを直接編集して、以下のようにfdt行を追加してdtbファイルを指定しないといけない。

label l0
  menu label Ubuntu 21.04 5.11.0-1007-generic
  linux /boot/vmlinuz-5.11.0-1007-generic
  initrd /boot/initrd.img-5.11.0-1007-generic
  fdt /lib/firmware/5.11.0-1007-generic/device-tree/sifive/hifive-unmatched-a00.dtb
  append root=LABEL=cloudimg-rootfs ro earlycon

HiFive Unmatchedが届いた

2021-05-31T18:44:00.003+09:00

RISC-Vの話は、実際のシリコンでの話は少く、大概エミュレーター作ったとかFPGAに実装してみてるとかが多く、(FPGAじゃない) 実際のシリコンでの話ってのは少ない。シリコンのデザインをしてる会社のプレゼンテーションを見ると大体このくらいのパフォーマンスという話は出ているが、実シリコンの話はプレゼンテーションの中の(都合のよい)話でしかなく、ソフトウェアエンジニアであれば、実際のシリコン上での動作を見てみたいものだ。

ということで、半年前くらいにオーダーしてたHiFive Unmatchedが届いた。このボードはSiFiveのSoC (SiFive Freedom U740) を載せており、しかもPCIe、NVMeスロット付という自分が待ち望んでいた感じのもの。ただしお値段は$679+4,200円。Mac Mini買える値段。

簡単にUNIX Benchmarks走らせた結果。RasPi3クラスかなって程度だが、コンパイラ自体の成熟度が増せばいろいろ違うだろうし、そもそもこのテストはSDカード上で行っているので、ストレージをSDカードからNVMeに変更すればまた違う

   BYTE UNIX Benchmarks (Version 5.1.3)

   System: unmatched: GNU/Linux
   OS: GNU/Linux -- 5.11.10 -- #1 SMP Wed Apr 7 17:37:34 UTC 2021
   Machine: riscv64 (riscv64)
   Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
   08:19:19 up 16 min,  1 user,  load average: 0.32, 0.23, 0.21; runlevel 2020-12-17

------------------------------------------------------------------------
Benchmark Run: Mon May 31 2021 08:19:19 - 08:47:43
4 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables        4443367.3 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     1189.1 MWIPS (9.8 s, 7 samples)
Execl Throughput                               1502.3 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks         85504.8 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           40618.3 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        116919.4 KBps  (30.0 s, 2 samples)
Pipe Throughput                              299710.9 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  54294.3 lps   (10.0 s, 7 samples)
Process Creation                               2426.7 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                    905.7 lpm   (60.1 s, 2 samples)
Shell Scripts (8 concurrent)                    358.4 lpm   (60.1 s, 2 samples)
System Call Overhead                         586221.6 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0    4443367.3    380.8
Double-Precision Whetstone                       55.0       1189.1    216.2
Execl Throughput                                 43.0       1502.3    349.4
File Copy 1024 bufsize 2000 maxblocks          3960.0      85504.8    215.9
File Copy 256 bufsize 500 maxblocks            1655.0      40618.3    245.4
File Copy 4096 bufsize 8000 maxblocks          5800.0     116919.4    201.6
Pipe Throughput                               12440.0     299710.9    240.9
Pipe-based Context Switching                   4000.0      54294.3    135.7
Process Creation                                126.0       2426.7    192.6
Shell Scripts (1 concurrent)                     42.4        905.7    213.6
Shell Scripts (8 concurrent)                      6.0        358.4    597.3
System Call Overhead                          15000.0     586221.6    390.8
                                                                   ========
System Benchmarks Index Score                                         260.2

------------------------------------------------------------------------
Benchmark Run: Mon May 31 2021 08:47:43 - 09:16:48
4 CPUs in system; running 4 parallel copies of tests   

Dhrystone 2 using register variables       17753848.1 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     4712.2 MWIPS (9.9 s, 7 samples)
Execl Throughput                               5703.9 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        159065.0 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           65531.5 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        208282.9 KBps  (30.2 s, 2 samples)
Pipe Throughput                             1179603.9 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 248734.2 lps   (10.0 s, 7 samples)
Process Creation                               9186.8 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   2695.8 lpm   (60.1 s, 2 samples)
Shell Scripts (8 concurrent)                    395.6 lpm   (60.1 s, 2 samples)
System Call Overhead                        2176448.1 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   17753848.1   1521.3
Double-Precision Whetstone                       55.0       4712.2    856.8
Execl Throughput                                 43.0       5703.9   1326.5
File Copy 1024 bufsize 2000 maxblocks          3960.0     159065.0    401.7
File Copy 256 bufsize 500 maxblocks            1655.0      65531.5    396.0
File Copy 4096 bufsize 8000 maxblocks          5800.0     208282.9    359.1
Pipe Throughput                               12440.0    1179603.9    948.2
Pipe-based Context Switching                   4000.0     248734.2    621.8
Process Creation                                126.0       9186.8    729.1
Shell Scripts (1 concurrent)                     42.4       2695.8    635.8
Shell Scripts (8 concurrent)                      6.0        395.6    659.3
System Call Overhead                          15000.0    2176448.1   1451.0
                                                                   ========
System Benchmarks Index Score                                         737.3

Windows 10Xがなくなった今、今年最大のオモチャかも

サードパーティ製IMEは、Web Browserのプライベート・シークレットウィンドウなんて考えてくれない

2021-05-21T21:57:00.001+09:00

最近のブラウザは、プライベート・シークレットモードが搭載されている。このモードになれば、ブラウザはCookieを保存しないとかいろいろプライバシーを考慮された動作になる。ただ、いくつかの言語 (とAndroidのようなソフトウェアキーボードを使う場合)、IMEというものを仲介して文字を入力するため、プライベートモードであっても入力履歴はIMEが保存してしまうかもしれない。そのため、入力履歴を学習しないようにするのを通知する機能というのがある。

Androidで言えば、InputMethods.IME_FLAG_NO_PERSONALIZED_LEARNING、Windows 10 20H1以降のText Service FrameでのIS_PRIVATEがそれだ (IS_PRIVATEの話は以前のブログ参照)。なお、GTKも4以降で機能を追加してもらった。この機能を使うことでプライベートモードであれば入力履歴を学習しないようになる。ChromiumやFirefoxではこれを使っているのでプライベートモードでは学習しないようにしてる。

ただ、この機能が動作する条件がもう一つあって、IME側でも対処が必要であるということ。この機能をちゃんと使うのは純正IME (Androidで言えばGBoardとかGooglen日本語入力、Windowsで言えばMicrosoft IME) くらいしかない。Androidの場合だとサードパーティ製IMEでこれを使っているのはあるかもしれないけど、どうも徳島にある某社のATOK (Windows版、Android版) はこの機能を使ってない模様。自分としては (毎月330円払っているユーザーとして)直してほしいのだけど、彼等はこういうところに興味がないから言ったとしても難しそうな気がする。

なお、ここで触れてない (本社がクパチーノにある) 某OS は未だに存在しない機能の模様なのだが、プライバシーとかを最近重視しているのであれば、実装してほしい。

CSS疑似クラスの:read-onlyと:read-writeが仕様通りに実装されることになった

2021-05-21T09:51:00.004+09:00

いろんなやりとりを仕事がらするのだけど、自分のイメージ的には、WebKitは仕様上間違ってるという話を振れば、直してくれることが多くて、BlinkはQAが変な方向に持っていくか、開発者が斜め上の方向の話にしてしまいwontfix扱いになるということが多々ある。

最近やっと直す方向になった、CSS疑似クラスの:read-only / :read-writeがそのパターン。

元々は、Geckoが-moz-プレフィックス付きで実装してたものの一つで、その後、WebKit (確かBlinkに分かれる前) に実装されてた。しかもプレフィックスなしで。実装されたとしても、そもそも仕様として固まっていないものだったので、いろいろと差異が出るので、ちゃんと仕様として書かれたのだが、それが今回の発端である。

仕様がそもそもその時点のブラウザとは違う定義をしていたので (プレフィックスがあれば、別にいいやとは思うのだが、特にWebKitとBlinkがプレフィックスなし)、「これどういうこと？」と思い、WebKitとBlinkに対してバグを登録した。仕様自体を変更するという議論もありだと思っていたので、それぞれ (AppleとかGoogle) がやってくれるでしょ？ってことだしね。

WebKitは、さくっとこのバグを修正。エッジケースでまだ間違ってることはあるだろうけど、こっちが指摘した動作に関しては修正してくれた。

で一方、Blinkはというと、「これGeckoとかと同じ動作にしたからこういう動作なんでwontfix」。という結論に。個人的には「え？ならCSSWGで議論してよ」と。なぜ彼らはwontfixにする際に仕様に対してのコントリビュートとかWeb Platform Tests書くとかしないのかなぁと。たぶん人によるのだけど、残念ながら個人的にはよくあるパターン。

こういう状況だとGecko側もどうしようもないので (しかもGeckoだけプレフィックス付きだし、プレフィックス外すのだったらこれ結論必要だから) 困ると。ということで、CSSWG行きになった。(wontfixと言った張本人がなぜそっちに議論を移さないのかと本当に思うんだが)そこで議論のやり直しが発生した。

結論書くと、結果としては仕様を変えないということになり、emilioがGecko側をプレフィックス削除とともに仕様通りに修正を行った。

さて、問題はwontfixにしてしまっているBlink側ということになる。emilioがそのバグを再オープンし直したが、つい先日やっと直すことになったようで、そろそろBlinkでも直りそうということに。やれやれ。

そもそもBlinkは他の2つ (Gecko、WebKit) に比べて圧倒的な人的リソースを持っているわけだし、シェアも圧倒的なのだから、こういう仕様とは異なる動作の修正にリソースを割いてほしいと思うのだけど。。。。無理かなぁ。。。

2020年、今年買ったもの

2020-12-24T00:05:00.007+09:00