低リソース OBC でもC2A coreを安心して使えるように，Coreのパラメタ設定方法やリソースチューニングの方法を改善する

[meltingrabbit]

概要

低リソース OBC でもC2A coreを安心して使えるように，Coreのパラメタ設定方法やリソースチューニングの方法を改善する

詳細

• 現在，CoreのCmdだけで100個以上あったり，各種テーブルがそれなりにメモリを消費したり（とくにBCTなど），Coreがリッチになってきている
• User側が検討中のOBCでC2Aが使用可能かなどをかんたんに判断できるようにするべき
• また，Coreはパラメタなどをチューニングすることで低リソースOBCでも使える設計にしているが，そのチューニング方法がC2Aを熟知していることを必要とするので，わかりやすくする．

close条件

とりあえず考えて，方針を決めたら

[meltingrabbit]

これまでの議論を簡単にまとめる

Coreパラメタのuser設定について

• https://github.com/ut-issl/c2a-core/blob/f2aa923e0690c9dde0b735aa710ff370cf0ed0d8/System/EventManager/event_logger.h#L60-L63 のように，引き続きパラメタについての説明はしっかり書く
  • パラメタ設定は user/Settings に集約しているが，そのパラメタから必要なメモリなどの推定値が出るような仕組みがあるとありがたい？
• https://github.com/ut-issl/c2a-core/blob/f2aa923e0690c9dde0b735aa710ff370cf0ed0d8/System/EventManager/event_logger.h#L114-L116 のように，Coreが想定する最小要求を見たなさないパラメタは弾かれるような仕組みを入れつつある
  • 一方で，ビルド前にわかりたいなどの要求もあり（OBC選定時など）
  • 逆に，ある設定パラメタ P_SIZE があったとして，現状 P_SIZE をUserで編集可能だが，Coreが P_SIZE >= 4 を想定（要求）しているのであれば， User側で設定するのは P_SIZE ではなく P_ADDITIONAL_SIZE などとし， Coreでは以下ようにする？（これはこれで，結局最終的なSIZEがなにになるかわかりにくいという問題もあるので，鈴本個人的にはあまり好きではない）

#define P_MINIMUM_SIZE (4)
#ifdef P_ADDITIONAL_SIZE
#define P_SIZE (P_MINIMUM_SIZE + P_ADDITIONAL_SIZE)
#else
#define P_SIZE (P_MINIMUM_SIZE)
#endif

• Coreの機能は選択性だが，それぞれがどれぐらいメモリを消費するかなどがわかりにくい
  • とはいえ，個別パターンについて提示するのは大変なので，たとえばCoreのリリースのたびに， "最低限C2Aとして動くための最低要求" をREADMEなどに書いたほうがいい？
  • "最低限C2Aとして動くための最低要求"，は数パターン（例えば，本当にminimumなパターン，一般的に使われるxxxやyyyという機能があるパターンなど）あってもいいかも
  • とは言いつつ，結局は詳細な必要リソースはあまりにも環境に依存しすぎるので，最低要求というより ...というボードで...という使用用途で使った実績がある といった，使用実績リストがあったほうがいいのでは？ と思ったり．
    • これは https://github.com/ut-issl/c2a-core/issues/168 で記載予定．近いうちに4種類ぐらいの情報を掲載予定 & 今後も増えていく予定．

コマンドと機能

• できれば，C2AにApp（や機能）をインストールしていくといった（npmみたいな）機能があるといいかもしれないとは思う
  • が，現在のC2Aの構造上，直ちに実装するのは不可能
• Coreにあるコマンドを以下のように分類してUserに提示するなどはあり？
  • C2Aとして動く最低要求のCmdセット
  • 一般的にC2Aとしたら必要だと思われるCmdセット
  • 選択機能ごとのCmdセット
    • その機能を使うのに必要なCmdセット
    • その機能を便利に使う or Utilのための補助Cmdセット
• C2Aとして動く最低要求のCmdセット あたりはそもそもUserがいじれないように（CmdDB上で消せないように，とか，そもそもUserとCoreでDBをわけるとか？）するのもありかもしれない