Franco Kernel およびさまざまなデバイス用のその他のアプリケーションの開発者である Francisco Franco へのインタビューのパート 1。
私は最近、史上最も人気のある Android カーネルの 1 つである Franco Kernel の背後にいる人物にインタビューする機会に恵まれました。 現在、カーネルは、さまざまな Nexus および OnePlus デバイス、Google Pixel / Pixel XL など、さまざまなデバイスで利用できます。
このパートでは、フランシスコ フランコのカーネル開発への道のりと、Android が長年にわたって経験してきた変化についての彼の意見について話します。
私は Adam Conway です。フランコ カーネルの開発者であるフランシスコ フランコにインタビューするために XDA に出演しています。 自己紹介をしてみませんか？
確かに、あなたが今言ったように、私の名前はフランシスコです。もう 100 万年も XDA を使っていると思います。 あらゆる種類のことを行ってきました。 カーネル、 アプリ、しばらくすると疲れるので、最近はカーネルを少しサボるようになっていますが、ほとんどのデバイスではまだ全力で取り組んでいます。
そうですね、あなたの作品については多くの人が知っていると思いますが、作品の背後にある実際の人物については知らない人も多いでしょう。 それで、本当にカーネル以前に何か過去の経験があるのでしょうか？ 事前にコンピュータサイエンスの学位などのようなものはありますか？
他の子供たちと同じように、私は常にコンピューターに情熱を持ってきました。 18歳になった後、他の人と同じように大学に行くことを決め、大学を受験していたと思います。 コンピュータサイエンスか何かだったけど、1年くらい経って、自分が実際に情熱を注いでいるものは違うと思った について。 その年以降、口だけで何も行動が伴わなかったため、私の期待は低くなり始めました。 退屈だと感じ始めた - 私が他の人より優れていたからではなく、私はただ平均的だった - しかし、実際の訓練 そうではなかった その通り 私が欲しかったもの。 それで両親に相談しましたが、両親は私がそのことにあまり満足していないことを知っていました。 2010 年のクリスマスに、私は初めて Android スマートフォンを手に入れました。 LG P500 は格安携帯電話で、非常に安価ですが、Linux を実行していることはわかっていました。大学での私の好きな分野はコンピューター アーキテクチャか何か、オペレーティング システムでした。 そして、私たちはシェルについて少し学び、Linux カーネルについて少し話していました。 カーネルとカーネル内のすべての接続、および実際のオペレーティング システムの一部でした。 だった
魅力的な 私にとって。 そして私は友人と一緒に古いラップトップ用の Linux カーネルを再構築し始めました。 そうすることでラップトップを 100 回ほどクラッシュさせましたが、その過程を通じて私たちは学びました。 それから私は LG で遊び始めました。最初にやったのは、パフォーマンスをもう少し向上させようとしたことだと思います。なぜなら、そのデバイスは実際にはかなりひどいものだったからです。 したがって、私にできる最善のことは、実際のカーネルの標準的な Linux カーネルパラメータを調べることでした。 メモリ管理などを考えて、既存のものよりももう少し良いものを探してみてください。 そこには。 その時は少し楽しかったです。以前のインタビューでこれについては話さなかったと思いますが、当時、そのデバイスは YAFFS と呼ばれる古いファイル システムを使用していました。つまり、Yet Another Flash という意味です。 ファイル システムですが、RAM バックアップのスワップ ディスクのようにマウントしようとするとかなり遅かったので、詳細は覚えていませんが、あらゆる種類の異なることを行いました それを実験した結果、最終的にメモリ RAM の上に Dalvik をマウントすることになりました。ご存知のとおり、RAM は再起動するたびに失われるため、再起動するたびに再構築する必要がありました。 再起動する時間です。 しかし、アプリケーションを開いたり、ベンチマークを実行したりするのがかなり速くなったので、満足しています。 それでその後、私はもう少し深く考え始めて、デバイス用の LG のカーネル ソースをコンパイルしようとしました。そして、あらゆる種類の悪いものを作成しました。 判断やあらゆる種類の間違い - Wi-Fi ネットワークでも何でも - 何も持たない人から想像できるすべてのこと 経験。 楽しかったです、とても勉強になりました。 それを 1 年か 6 か月続けた後、私は少し集中力が増し、ダウンロードを得るために何をしなければならないかが少しわかってきたと思います。 それが私たち全員が最終的に望んでいることです。 その後、なんとか寄付を集めて他のデバイスに移行することができました。 Nexus S、次に Galaxy Nexus、そしてその期間を経て、なんとか最初のアプリをリリースできたと思います。 私はとても幸運だったと思います。新しいデバイスを購入するための資金を調達できたので、そこから爆発的に成長しました。 結局のところ、私は XDA とは言いませんが、XDA のおかげだと思います。 プラットフォーム XDA が提供するものです。
そして、その背後にあるのはコミュニティです。
はい、はい、プラットフォームのことです。それはコミュニティであり、実際のフォーラムです。 聞いている人なら誰でも、これはお金をもらったスポンサーでも何でもありませんし、これを言うために私もお金をもらっているわけではありません、これは真実です！
ビデオはありませんし、人々はあなたの頭に銃を向けているのを見ていません、大丈夫です。
ははは、そうだけど、これを言うことでお金をもらっていると誰かが言うだろうから、言っておきます！ でも、そう、そう、それは私にとってクールなものを構築し、多くを学ぶための素晴らしいプラットフォームでした。私はほとんど間違いを犯してそこですべてを学びました、そして学習においては今でもかなりの問題を解決しています。 Xiaomi Redmi Note 3 を破壊してしまいました。えー、ブートローダーが破壊されただけです。 そこで、そこに置いている Windows コンピューターに再度接続し、すべてを再フラッシュする必要があります。そして、約 3 か月間ここに置かれています。 私がそのデバイスに注意を払っていないことで、みんなからあらゆる種類の憎しみを受けているので、私はまだ[間違い]を犯していると思います、 何年も経った今でも、学ぶべきことはまだあります。この旅を経験できたのはとても幸運でした。 素晴らしい。
まあ、あなたが始めたところを見ると... LG P500でしたっけ？
ええ、ええ。
それは何年前のことですか？ だって、それは Android のオリジナル バージョンの頃だったはずですよね? フロヨあたりか？
はい、これは Froyo に同梱されており、数か月後に Jingerbread にアップグレードされました。 そのデバイスは 2010 年か 2011 年の初め、おそらくそれより前のものだったと思います。 XDA のアカウントが 2010 年 12 月に作成されたことはわかっていますが、デバイスは事前に入手していました。 だから、おそらくその頃だと思います、そうですね。
それ以来、Android はパフォーマンス面でどのように進化しましたか? 昔カーネルを書いていたのと今カーネルを書いているのとでは、どのように変わりましたか? そして、この変更についてあなたの意見はどうなっているでしょうか。
カーネルに関しては、実際の Linux カーネルと、Android チームが実際に望んでいたすべての変更を加えて進化したと思います。 特定の Android リリース用に実装されるため、カーネルが持つ特別な機能のほとんどは、必要なものに基づいて決定されます。 船へ。 しかし、実際のパフォーマンス、より多くのコアは実際には非常に役立つと思います。当時は実際にそれを実現する方法がなかったからです。 このスレッド (原文どおり) を移動するか、バックグラウンド スレッド、または少なくとも実際のリアルタイムを介したネットワーク リクエストを想像してください。 糸通し。 これは、ここ数年で最も大きな変化だったと思います。作業を分散する方法が増え、誰もが少しの CPU シェアを獲得しようとして Android の速度が低下することがなくなりました。 何よりも、Linux に支えられたマルチコアと実際のマルチスレッドだと思います。 それが最大の変化だと思いました。
ああ、それでは HMP と EAS についてどう思いますか? なぜなら、明らかに EAS は新しいものであり、少数のデバイスでのみ使用されているだけだからです。たとえば、Google Pixel をお使いですか?
はい、現在私は Galaxy S8 を使用していますが、Pixel も持っています。 私は両方ともそこまで詳しくは知りませんが、特定の時間にデバイス上で何が起こっているかに基づいてマルチクラスタデバイスがどのように動作するかを実装したものにすぎません。 2 つの異なる消費電力を持つ 2 つの異なるクラスターを実行するのは、非常に困難です。 タスクが上下に移動するという期待に応えなければなりませんが、そこには待ち時間が伴います。HMP は、 私の記憶が正しければ、HMP が実際に使用される前に、Samsung は初期の ARM 用アーキテクチャを持っていました。 最初の 4 つのコア (低電力コアなど)、または 4 つの高性能コアを使用していたが、それらが決して実行されなかった実装。 同じ時間です。 しかしその後、HMP を使用すると、いつでもコアを使用できるようになり、タスクがあるクラスターから別のクラスターに、またはその逆に移動するだけで機能しました。 しかし、実際にどのような周波数が使用されるかを決定するために、これをガバナーに示すためのスケジューラからの情報はそれほど多くありませんでした。 特定の時間なので、[約] 20 秒以内に何が起こっているかを理解しようとして、そこで何が起こったかに基づいて何をすべきかを決める、というようなことに対処する必要がありました。 する。 EAS、それは将来何が起こるかを理解し、それに基づいてリアルタイムで決定することです。 各コアの電力出力、そしてそれは大量の計算と複雑なことを必要とします。 背景
それを裏付けるエネルギーモデルなどです。
はい、そうですね。かなり複雑です。詳しくは知りません。たくさんのドキュメントを読んだのですが、非常に複雑で、ただスイッチを入れてすぐに使用できるようにするだけではありません。 XYZ 電話機に EAS を実装できないかという質問をよく受けます。 私の返事はいつも 「ノブを回すわけではありません。そんなものではありません。実装するには Google 社員と Linaro の社員からなるチーム全体が必要でした」 そして、何かを移動したり、何かをしたり、テストしたりする必要がありますが、それはあまりにも大変な作業であり、かなり面倒です 盲目" そして…ええ。 それは難しい。
つまり、自分が何をしているのかを正確に把握する必要があり、それは一人で行うような仕事ではないのですか？
そう、自分が何をしているのかを知る必要があります。パッチを選択してマージすることは誰でもできますが、実際にテストして正しく動作することを確認するには、適切なマシンが必要です。 各コンポーネントの電力使用量を検出するには、カーネル上に各コアの電力を書き込むことができる多数のテーブルがあり、それに基づいてコードが何をすべきかを決定します。 する。 かなり複雑です。 それがすべての問題に対する明確な解決策であるとは思いませんが、現時点で最善の解決策であることは間違いありません。
それで、それは改善だと思いますか？
そうですね、何マイルも何マイルも離れたところにあります。 これは、HMP やその他のアーキテクチャからの明らかな改善です。将来何が起こるかを理解できれば、より迅速に対応できるからです。 あらゆるリクエストやデバイス上で起こっていることすべてに対応するため、Google Pixel は非常に高速でスムーズです。すべてがほぼ瞬時に行われるためです。 リアルタイム。 周波数を上下に動かすのが、期待されるパフォーマンスを達成する最も簡単な方法です。
それでは、将来 EAS の採用がさらに増えた場合、それがカーネルに関してあなた自身の開発にどのような影響を与えると思いますか? 今後も HMP を使い続けるでしょうか、それともすでにリリースされているエネルギー モデルを使いますか? たとえば、OnePlus 3 では、[ROM 開発者] は Google Pixel for EAS のエネルギー モデルを再利用しています。 自分がそのようなことをしているのを想像できますか？
私はおそらくそれはしません。そもそもデバイスに EAS が同梱されていないのであれば、おそらくいかなる方法や形式でも実装しないでしょう。 先ほども言ったように、これは非常に長いプロセスであり、XDA にはこれらのエンジニア以上に詳しい人はいないので、私たちはただ神を演じようとしているだけだと思います。
Android とカーネルの将来について話していますが、最近の Android Oreo リリースについてはどう思いますか? その変化は良いことだと思いますか？ 新しいカーネルのコミットを確認しましたか?
Nexus 6P と Nexus 5X ではカーネル側にそれほど多くの変更はなく、所々に小さな修正が加えられただけです。 Google Pixel では、EAS の実装を繰り返し、バインダー セクションの改善に時間を費やしました。バインダーがプロジェクトと連携するようになったからです。 Treble では、異なるパッケージを分割するようなものなので、バインダーを改善して異なるパッケージに分割するために 50 または 100 の異なるパッチを適用する必要があります。 プロセス。 それ以外は、大きなリリースのための通常の作業でした。 新しいプラットフォームのリリースがある場合、通常はカーネルをそれほどいじることはありません。 カーネルでは、実際には多くの QA が必要です。ある点を変更すると、別の点に影響を与えることがあります。 サブシステム。 これが通常の動作であり、プラットフォームのアップグレードの間にカーネルのバージョンが変わらないのはそのためです。 それはただ大変な作業です。 通常はそれほど価値はありませんが、そうです、主にバインダーに関するもの、スケジューラーの一部、そして通常のセキュリティ修正でした。 それらすべてに目を通しましたが、特に心に引っかかるものはありませんでした。 私の注意はバインダーだけに向けられました。
ああ、それでは本当に標準的なものだけです。
はい、それらは非常に複雑なので、詳細については尋ねないでください。
これはまったく別のトピックですが、ext4 に対する F2FS についてどう思いますか? なぜなら、F2FS は不安定で、問題が発生する、という人がたくさんいるからです。ちょっと気になったのですが、それについてどう思いますか。
ファイル システムは非常に難しく、あちこちに可動部分がたくさんあるため、詳細についてはわかりません。 Google エンジニアのテストによると、F2FS は ext4 よりもパフォーマンスが速くなく、その上、 彼らは Google Pixel 向けのテストを行っていましたが、F2FS はサポートを提供していませんでした…ファイル ブロック暗号化だったと思いますが、ext4 はサポートを提供していました それ。 つまり、それだけで、それを廃棄するだけです。 2 つのことを考慮する必要があります。ext4 は、さまざまな企業の多くの非常に賢いエンジニアとともに約 20 年間開発されており、彼らは自分たちが何をしているのかを知っています。 私の記憶が正しければ、F2FS は Samsung によって実装されました。 これは非常に新しいファイル システムであるため、これほど複雑なものを改善し、反復するには時間がかかります。 iOS でリリースされたばかりの Apple ファイル システムからわかりますが、Mac でも同じことを行う予定です OS。 物事には時間がかかり、これらのことを正しく行うには大規模なチームが必要です。 私は「動いているなら触るな」の大支持者で、現在私たちが持っているものは動いていますし、パフォーマンスに問題が生じるとは思えないので、そうする理由はないと思います。 それをめちゃくちゃにしてください。
ああ、それは十分公平です! どうですか SDカードFS FUSE から切り替えられていますか? それについてどう思いますか？
これは、古い FUSE ファイル システムが Android で発生した最悪の事態の 1 つであったために起こりました。 パフォーマンスはひどいもので、カーネルとユーザー空間の間で多くのシステム コールが発生していましたが、SDCardFS ではそれが適切に行われるようになりました。 これに対処するのは通常のファイル システムです。これも非常に複雑なことなので詳細はわかりませんが、私がやったこと Android チームのさまざまなポッドキャストを読んだり、見たり聞いたりしたところ、基本的に古いバージョンの問題はすべて修正されました。 システム。 あれは本当にひどかったし、パフォーマンスもひどかった。
このボタンをクリックしてパート 2 をチェックしてください。