Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Rust で RTOSを考える

Rust で RTOSを考える

TOPPERS開発者会議2021 (2021/10/24) の LT で発表させて頂いた資料です。
https://www.toppers.jp/devconf2021.html

Ryuji Fuchikami

October 24, 2021
Tweet

More Decks by Ryuji Fuchikami

Other Decks in Programming

Transcript

  1. 自己紹介 (渕上竜司/Ryuji Fuchikami) • 平日は某企業で働くサラリーマン (以下、趣味の経歴のみ) • 1976年生まれ 全国転々としつつも結局、福岡が一番長く、今も福岡在住 •

    1998~ μITRON仕様 Real-Time OS HOS-80 をリリース • 現在 HOS-V4a にて各種組み込みCPUに対応 (組み込みRustも実験中) (ARM,H8,SH,MIPS,x86,Z80,AM,V850,MicroBlaze, etc.) • 2008~ FPGA用ソフトコアSoC環境 Jelly をリリース(MIPS互換コア) • 現在 Zynq 上にて Real-Time GPU や LUT-Network の実験など 各種 Real-Time コア開発の実験場と化す • 2018~ LUT-Network用の環境 BinaryBrain を開発中 • 微分可能回路記述にてFPGA回路自体をそのまま深層学習 • 2021年現在、Rust勉強中 • リアルタイムコンピューティングを(趣味の範囲で)探求中 • 電脳メガネ計画(いつかやりたい電脳コイルの世界) • Real-Time 画像I/O (カメラ[IMX219] & OLED 1kfps駆動) • Real-Time GPU開発 (frame buffer無し、ゼロ遅延描画) • Real-Time DNN開発 (超低遅延DNN認識) 2 本日の発表は個人的見解であり、所属する組織とは関係ありません 娘に書いてもらいました
  2. 私の活動領域と環境 3 • アカデミックでもビジネスでもなく、ホビーとしてのOSS • 論文も書かなければ、特許も出さないという、無責任な立ち位置 • 産学連携や、各種商用RTOSのようには、ちゃんとしてないです。 m(_ _)m

    • 今回を動機に勉強を始めたところなのでRustは初心者です。 • Xilinx社の ZynqMP という Cortex-A53(Linux)と Cortex-R5 と FPGA が1チップになった欲張りセットなエッジプロセッサでいろいろやってます。 今日はここでRustを やってみたお話 (ARM Cortex-R5) https://japan.xilinx.com/products/silicon-devices/soc/zynq-ultrascale-mpsoc.html
  3. やってみたことと、やろうとしていること • ITRON(HOS)を移植して、その上でRust使ってみた • ITRONが動いてしまえば、Rustは予想以上に簡単に試せる • configurator が build.rs から呼べるのは素敵

    • kernel_id.h をどうするかは課題 • なのでC使わずにRustでRTOSを作れないか検討中 • Rustの勉強に良い題材。 • C言語よりもいろいろ楽できそう。 • カーネルとアプリを跨いだ最適化が期待できそう • 「RustらしいRTOSの仕様ってどうあるべき?」で悩み中 4 あまりにあっさり動いて びっくり 悩みつつも「論よりRUN」で タスク切り替えと割り込みと タイムアウトまでお試し
  4. ID方式 vs. Rust • ITRONのオブジェクトはID管理、Rustだとどうするべき? • ID方式は所有権の概念が無い。Rustの恩恵にあずかれない • ちゃんとRustできれば E_IDとか、E_DLTとかそもそも不要なエラーもあるのでは?

    • IDでないならそれに代わる、タスク/セマフォなどのオブジェクトを指すハンドルは 誰がいつ生成/削除する? • 誰がライフタイムを管理するのか? 全部 static? • どうやって利用者(タスク/割り込みハンドラ)にオブジェクトの利用権を渡す? 全部 static経由? • クロージャに束縛して渡すべきと思われるがテクニックが難しく、no_std で実現でき るのか不透明。 6
  5. 最初から何でも装備 vs. crate機能拡張 • 昔はインターネットもなく、そこにあるものしか使えないのが普通だった • なのでITRON4.0 でいろんなAPIが定義されていたのは良かった • 内部的にはHOSもマイクロカーネルと同期オブジェクトのモジュール構造はあった

    • Rust の場合、クラウドから欲しい機能が降ってくる • セマフォクレート、メールボックスクレート、みたいなのが後からどんどん自由に追加 出来るようにできないか? • うまくプリミティブな機能だけでシンプルなカーネルが定義できないか? • RTOSはある意味CPUやIRCに対する HAL (Hardware Abstraction Layer)ではないか? • 転じてカーネルに先立ってPAC(Peripheral Access Crate)書いておくと楽だと感じ ています。 8
  6. Makefile vs. Cargo • 何をいまさらと言われそうですが • Cargo 環境はとっても便利です。 • 組込みRTOSはクロスコンパイルが基本、makefile時代は

    • コンパイルする環境さまざま • コンパイラメーカーさまざま • コンパイラについてくる make ツールさまざま • 同じCPUに対しても各社がコンパイラ出してきて全部方言が違う • makefileだけでなく、アセンブラもリンカも方言だらけ • 全て同じようにビルドできるソースとビルドシステム作るのはとても困難 9 アーキテクチャに依存しないビルドシステムだけでRustの価値は計り知れない
  7. 思っていたほど既存のコレクションとかが使えない • 最悪実行時間(WCET)が見積もれなければならない • 実行時間の保証のないアルゴリズムはOSサービスコール内で使えない • 最大割り込み禁止時間観点で、途中で割り解除とかしたかったり • 公平性ではなく、デッドライン厳守のスケジューリングポリシーが必要 •

    タスク優先度ベースのオブジェクトを跨いだ管理機構の入れ込み余地 • Priority inheritance protocol とか • Dynamic priority exchange server とか Rustには空間リソースの所有権はあるけど、時間リソース保証に関しては 自力で準備が必要? 11 Rustで楽できるかなと思っていたのですが...
  8. 所有権とライフタイム難しい • コンテキストを跨いだ所有権のやり取りが難しい • 初心者の私にはなかなかハードルが高い • 特に割り込みハンドラ • Deferred procedure

    call やるときどうする? • HOSではパラメータシリアライズしてFIFOに投げ込んでいるが... • 遅延してる間にターゲットが削除されるとかありえるが Rust の思想と合 わない? • そもそも排他区間でロックしないので、その間の割り込みハンドラから見た 対象オブジェクトの状態が不確定。 • 排他区間を抜けるまで状態不確定なものに対してリクエストを投げると いうのがRust思想外かも? 12
  9. 目指したい方向性 • ITRONの弱い標準化+Rust • Rustで書いたRTOSをITRONと言うつもりはさすがにないですが思想は大事。 • 思想だけ継承できないか • 「ITRON経験者 +

    Rust知識 → 素早く意味がわかる」 を目指したい • Rustのモジュール階層は弱い標準化思想には相性が良さそう • 基本機能として似たようなものを提供しておけば、細かい固有機能は #[cfg(target_arch = XXX)] などで、場合分けして個別事情で実装しても、使う側としてそこまで困らないと思う。 14
  10. 今後のRustに望むことなど • static の初期化でもっと何でも許容してほしい • コンフィギュレーターのような静的初期化をいろいろやろうとすると「mutable references are not allowed

    in statics」 となり許されていない。 • const fn の内での制約も同様。 • シンプルに未初期化の変数を許す方法が欲しいかも? • レジスタの退避は細かく制御できないか? • OS(アセンブラ)から呼ぶケースで壊してもいいものまで退避しちゃう。 • 割り込みハンドラだけは浮動小数点レジスタ使うときは自分で退避して欲しい (OS側で退避すると、使ってなかったら無駄な退避になる) • cargo run で組み込み環境への download&run できないか? • Makefileから cargo 呼ぼうかとも... • Macro 2.0 は楽しみ • 今のマクロでも出来ると思いますが、個人的には20年前に構造体メンバの詰 め込みソートががしたかったとかいろいろあって、マクロの拡充は楽しみです。 15
  11. 発表者アクセス先 • 渕上 竜司 (Ryuji Fuchikami) • e-mail : [email protected]

    • Web-Site : http://ryuz.my.coocan.jp/ • Blog. : http://ryuz.txt-nifty.com/ https://ryuz.hatenablog.com/ • GitHub : https://github.com/ryuz/ • Twitter : https://twitter.com/Ryuz88 • Facebook : https://www.facebook.com/ryuji.fuchikami • YouTube : https://www.youtube.com/user/nekoneko1024 17 本発表に関連するコードは下記で試行錯誤中です https://github.com/ryuz/rust_rtos お気軽にアクセスください