06:19 <whitequark> sb0: two small questions about the protocol.

06:20 <whitequark> 1) as I understand one of the goals for the rust runtime is to put the kernel into a buffer on the heap, such that large kernels can be loaded

06:20 <sb0> yes

06:23 <whitequark> the way I currently have tcp receiving side implemented is that it holds a pbuf in a TcpStream implementing Write, and gives out bytes from there

06:23 <whitequark> in principle I could figure out something such that small strings are parsed without copying or allocation, but this seems to have nontrivial complexity and unclear benefits

06:24 <whitequark> so for now I am allocating all strings on comms CPU heap on receipt (except for RPCs, where the contents is copied directly to the kernel CPU stack)

06:24 <whitequark> are you fine with that?

06:25 <whitequark> this only really affects flash storage and RPC exceptions

06:27 <whitequark> oh, and of course instead of mostly-zero-copy right now, I could always do one copy into a long extensible buffer and then return references into it

06:29 <whitequark> that's strictly worse for RPCs though because I would have to keep the contents of an entire serialized RPC in memory (like it happens now) whereas with the zero-copy scheme I'm going with in runtime.rs that's not the case.

06:34 <whitequark> oh and 2) right now there is length in the packet header

06:35 <whitequark> it's redundant for, I believe, every packet except LoadLibrary

06:35 <whitequark> and it prevents me from streaming the reply (or request for that matter) packets, since I don't know it beforehand

06:36 <whitequark> I suggest removing it from the header and instead transmitting the payload of LoadLibrary like all other byte buffers are transmitted

06:36 <whitequark> objections?

06:45 <sb0> 2) ok

06:48 <sb0> 1) also sounds ok, there are no long strings right?

06:48 <whitequark> nope

06:49 <whitequark> I might actually even skip allocating a buffer for the kernel

06:49 <whitequark> because the allocator I wrote is fragmentation-prone

06:49 <whitequark> just write it directly into kernel CPU memory

06:50 <whitequark> hm, or will that fail timings somewhere?

06:51 <whitequark> yes, this seems troublesome when doing handover if the network has a latency spike

06:58 <sb0> are you modifying the session behavior already?

06:58 <sb0> i.e. you could load multiple kernels into the device

07:03 <whitequark> not yet, i'm porting the old one