Sistana 的 options 管理略失败，给 Yanagi 添了一些堵。

Framework 几乎没动过……没有主要枝干的话是没法突然开出花来的。需要实现 Avilla 的 Account Gateway，还是不要用什么 qq://elaina@main/... 的鬼畜玩意了，这只是呈现，没有接口平面的废物罢了，但对这两者，如果没有特别意识到前者的交互贫乏，会很容易混淆起来。 说到底，人是不知道自己到底要什么的，毕竟在得到之前都没法准确描述，脑中的印象也会因认知改变。 上下文和事件描述两者本身就是冲突的……我们在 Avilla 中因此吃的苦太多了。 或许用 Entrypoint 避免使用模型类或许是可行的，模型类本身相对独立，但依赖的上下文生命周期太短，强制传递的信息以函数传参的方式，将生命周期绑定在业务逻辑上或许可行。虽然这样就无法使用 FastAPI 形式的 Depends，而需要使用描述符等方法。 之前我提出通过私有协定，setattr 在 method fn 上，类似 yanagi 在 __init_subclass__，或是采用装饰器方法扫描成员 —— 构造相应的 CollectContext。这种方法的问题只有严重依赖 Selection，但我觉得没法解决。 比如说消息发出的事件 on_message_created，写成 on_message_created(cx: Context, sender: Any, target: Any, message: Any, **kwargs)。 这个 **kwargs 是认真的吗……？还是感觉这样不可行，说到底我们要的到底是什么？

异星工厂的蜘蛛机甲的装备是用类似 Volume（体积）的方式约束的，例如 2x2, 1x3 等。 我觉得这一样能适用于技能组配置。

「在行为已经是反人类的前提下，无法讨论其是否文明与否。」

「类型检查器的 Real World 实现通常被视作一项工程难题。」

妈的，和苹果爆了

类似于这种的 badge 设计感觉还不错。

Flywheel 还是不怎么想做。
Launart 的重构将不可避免的破坏向前兼容性（API 接口变动）。
Yanagi 需要在 Flywheel 之后，并且架构还没完全确定。
Cronet / Cryonet……最好的办法是从 Google 的 Mojo HDL 生成出 C++ Bindings / Header，再使用 Cython 自带的 C++ Binding 功能与其交互。但这样需要改动由 naiveproxy 构造的构建系统（gh:GreyElaina/cronet-binaries）。

Tinymind 如果能在 Obsidian 里用就好了，就用 memos（或许叫其他的名字）那样的感觉。

Launart v0.9.x 希望通过整理现有的实现，设计一致的同构接口，对畸形的曲线救国设计进行纠正以解决现有的问题。

Context 将代替 Manager 参与到 Service 的 launch 中。通过 Context 中传递的由 manager 管理的 sigexit 和 stage 控制内部。然后造一套 serviceset 相关的 API 把服务的 task 全部用类似 TaskGroup、CancelScope 之类的做结构化并发。

而结构化并发其实可以不要，因为「不一定 graceful 就是一定不 graceful」，但需要让现有的架构更完善许多；最主要的修改就是 Context 来解决之前很肮脏的实现，其他的都没有太大关系。

打算将 Launart 的这次抽象也和 Sistana、Flywheel v3 一样先作为我的个人项目孵化。我主要实现的是 Context，以及改善 Sideload 的使用 —— 直接改成加入的时候以服务的簇为单位加入，然后解析完整依赖并更新到 Manager 里面。Drop statv，async with context.{prepare, mainline, cleanup}(): ... 啥的。我实在懒得想什么新的词了所以不用改了。

行为上似乎没啥变动，除了 Sideload 的部分被清掉了都还行。除了我稍微克制了一下，保留了 context.sigexit 而不是用什么 skippable 之类的花活，也没有想着要写纯函数表示的 Launch API（但这个真的很吸引人），这次算是为了修 BUG 而做的保守的重构。

今天除了捣鼓 rtwo 的内核源码外啥也没干。

其实也不是什么也没干，但是经过实验和他人经验，可以得知我之前尝试修改 msm-poweroff 有两点不可能：1）msm-poweroff 早就没有被启用且启用了也没法编译（ ld.lld 报告无法导入符号）；2）Motorola 系的设备从不进行 Warm Reboot，这意味着不可能通过 ramoops 获得 console 输出。

所以我 drop changes。「所以我放弃了音乐。」搞什么鬼不可能放弃啊。

其实也不是不可能，我找到了这篇博文，作者手动实现了一个 logstore 模块，将 kernel/panic.c 插入了 do_logstore，能将 kmsg 手动的写到一个文件上。 原文作者是在他的 Oneplus 8T 上实施的，他提到这以平台基于 msm-4.19，显然需要移植到 rtwo 的 5.10 平台上。

此外，原文作者将目的文件设做 /mnt/oplus/op2/last_panic.txt。显然这不适用于 rtwo 平台。我们需要一个在第一启动阶段（First Stage）就可用的分区。我翻阅 fstab.qcom 发现只有 metadata 是 rw（可写）的。Motorola Developers 群组称 metadata 分区足足有大概 60M 的空间，我的平台上这个分区的空间使用情况是 34.19M/62.00M，据他们所说算是绰绰有余，我将其设作 /metadata/kernel.log。

在之前的实验中，任一 GSI/DSU 环境都没能进入 Second Stage，在出现启动动画（boot animation）之前就发生了某种崩溃，关于发生了什么，MotoDev 的人员称其一定发生了某种 kernel panic，于是这点也得到确认，现在我需要一点时间去翻翻 kernel 的源码。

关于移植，我几乎原封不动照抄的 patchset 当然没能通过编译，在 5.10 上，我们需要通过 kmsg_dump_register 来获取 kmsg_dumper 实例，也就是说 panic.c 上的修改需要丢弃：kmsg_dump_register 的范式是回调，这部分的入口点函数 kmsg_dump 会逐个调用 dumper，而 panic.c 和 msm-poweroff 也确实会调用这个……总之，按照 kmsg_dump_register 来。

Flywheel v3 中要尽可能的与 Python 的描述符协议，至少是 __get__ 保持一致，主要是要直接支持 classmethod 和 property（最好是）。后者可以直接替代掉 Anycast。此外是提供一个类似 @property.setter 的 @endpoint.call 实现，以可以在单个 identity 上同时使用 Collect 与 Call。

我先写下以防止我忘掉：endpoint 默认的 call 返回的是 harvest，如果要实现 @endpoint.call，那么就得把这个返回 harvest 的 call 先实现为闭包，然后再用 partial 或其等价实现包起来。此外如果按照这种方法，仍然需要和上面对待 collect 的方法一样，应用 __get__ 描述符协议。

不知道什么时候才能把 sansio framework 点出来，这之前还有 awaitlet 集成得点出来，yanagi 也依赖于这个（或许不依赖，可以直接把 model 构造完连同 context 一起丢出去）。SansIO 可以直接实现例如 Matrix 和 ActivityPub 之类的，我比较感兴趣的实现，这方面的工作或许也有利于 Avilla —— 虽然标准化接口什么的仍然让人糟心，但至少这方面会迈出去结实的半步。