Ryo Suzumoto

## coreにexampleなどとして，開発用のミニマムなuserをいれる案 c2a-core リポジトリ ``` Applications Drivers/ ... Example/ maximum_sample_for_s2e/ main.c src/ src_user/... src_core/... ``` という感じ． 議論点としては， - sample がもつ src_coreをどうするか？ - 自身のroot をgit submodule？（原理的にできるが，再帰なってやばそう） - ここではcoreは持たない（rootをinclude pathにいれる？） - 現状のincludeの書き方だとだめ...

> ここではcoreは持たない（rootをinclude pathにいれる？） src_core/* を git ignore にいれて，rootとシンボリックリンクを貼れるようなsetup scriptを配置する？ そうすることで，中身を編集しながら開発ができる．

内部のmemberなどが秘匿値をpushしてしまった場合などは， https://docs.github.com/ja/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository からGCをリクエストできそう．

> S2Eのみでビルド 検証としてはこれで． ただ，ワーニングが多すぎる問題があるので，C2Aのみをライブラリビルドできるようなmakeファイルを準備して，それでワーニングチェックをする，という案もある． → https://github.com/ut-issl/c2a-core/issues/20 , https://github.com/ut-issl/c2a-core/issues/27 に分離 また，実行時間の検証はできない．

ひとまず開発はできているが，外部の人をどうするかなどの検討は，実際にやってみないとわからない． というわけで，ひとまずこのissueを iceboxにします．

> unixtime指定での削除 @shunichironomura 作ったとしても，上記の通り，不確定性が乗るので，削除コマンドのパラメタは，unixtimeとcmdidの両方（冗長だが）として，そのどっちもが一致した場合に消すといったバリデーションを入れることになるかなと思ってます． 地上システムとして > - UTLC受理時と同じOBC内ロジックを使うことで，指定したunixtimeでdeleteすることは可能である． > - 一方で， `OBC内ロジック` 内部で使われる絶対時刻基準（unixtimeとTIの対応元期）は，OBC内部で更新される可能性がある（OBCの内部で保有している絶対時刻ももちろん徐々にずれていくので）． > - したがって，delete時にinsert時と同じunixtimeを指定したとしても，delete時に指定したunixtimeから変換されたTIがinsert時のそれと一致する保証はない． **これが最大の問題** これは許容できますか？

OBC内部の時刻合わせの回数を減らすために， https://github.com/ut-issl/c2a-core/issues/183 というのはやろうと思ってます．

> というのが自然な気がしていて、このIDがC2AではTIになっているので、unixtime指定のTLCが打てたとしてもdeleteはTIなんじゃないかな。 個人的にもこれは正しい（DBでいうところのmaster key (id)はTIなので）とおもっていて，unixtmeはあくまでwhereで絞り込めるためのものなんですよね．本来は．（とはいえ，TLCキューをDBとみたとき，このunixtimeは勝手に変わりうるので，そういう意味ではちょっと違うかもしれない） なので，whereで絞り込んでidを取得するのはシステム側（このシステムを衛星内部で持つのか，地上システムで持つのかは要検討なのですが．．．．）だと思います．（ORマッパー的な） < `（ソフトウェアなどが）自身で登録したTLCを確実に削除する方法が欲しいです。` なお，２つ上の僕の投稿で引用している問題がクリティカルではないのであれば，そういうのは追加実装してもいいと思います． (※ deleteやwhere, idなどは，SQLの意味あいで使ってます．)

なお，衛星内部のマスター時刻をTIではなくunixtimeなどにする，は，宇宙空間にはNTPサーバーなどないので，現状はマスター時刻として必要な要件を満たさず無理だと思っています．

> TLC登録時のunixtimeに合うように登録後に時折TIを修正するという操作を入れうる場合、TIすらも固定されたkeyではなくなってしまうので、なにかkeyになるものを追加した方がいいかもですね... > 対応元期が変更される差分のオーダーはTIの刻み幅に比べて十分小さいということですかね？ に関連しますが，UTLの時刻がコマンドを打ってからどのぐらい先かによりますよね． せいぜい数日を想定していてそれであれば， `TLのTIをずらして登録し直す` みたいなものは回避できると思ってました（これ必要ならさすがに今の衛星時刻スキームだと限界が．．．） @ShingoNishimoto @shunichironomura ここらへんの温度感わかりますか？（どれぐらい先のものを登録しようと想定してますか？）