August update
Skip to first unread message
William ML Leslie
Aug 26, 2026, 7:29:47 AMAug 26
to cap-talk
Greetings,
This is a kind of broad update about things I'm working on. I don't have anything to announce, but I miss the regular updates that Shap used to give when we were working on Coyotos, so I figured it might be worth writing down my thoughts.
On my port of CapIDL to CapnProto - that is, using CapnProto to define all of the existing Coyotos IPC - I am currently trying to get some C tests working. These test my generated capnproto functions and types. With the clarity of hindsight, this project would have been a perfect candidate for test-driven development, and I think I just got too excited about making progress. I'll switch to TDD when I start generating Rust and other languages.
It is fairly slow going, difficult to focus on because it feels quite disconnected from where I want to be going. I still think it will be worth it, though. I am not sure how I want to license the project, since it must work with coyotos headers I need to either incorporate some coyotos source or completely rework those edges. Maybe I should just make it all gpl2+.
There were questions on doing capnproto without a heap; the way this works in this implementation is that if you try to allocate a list or struct that doesn't fit, you'll be given a "null struct". You can ignore this and continue working with it, but the better practice is to query if it's the null struct every time you allocate. We can make this an error in other languages.
On capimg - the state I left it in, it could generate disk images identical to the Coyotos' mkimage program. I haven't put any further effort into making it build seL4 images. There are a bunch of concepts in microkit that need to be translated over, and there's no dynamic spacebank implementation for seL4, although capimg could be useful even for static images.
On async - I've come back around to thinking that I might start implementing the objects I had planned in userspace first. It wouldn't be as efficient, but the objects themselves would be much more useful. The objects I had planned had limited stack space, for commands, data and capabilities. In userspace, these objects could be as large as they need to be. Not to mention, building all of the factories required to make this part of the TCB means I think I can do revocation of mappings safely. In userspace, there is room to play with different interfaces for some of these objects, including supporting the io_uring ABI and maybe something closer to CapTP. There's room for several different interfaces, I think. That also makes these easier to port to seL4.
Since this is all in userspace, I should also be able to go back to the pure Coyotos ABI rather than its own... thing.
So - that's where my work is. Is it worth discussing this stuff? Should I move it to its own group? Any other thoughts?
This is a kind of broad update about things I'm working on. I don't have anything to announce, but I miss the regular updates that Shap used to give when we were working on Coyotos, so I figured it might be worth writing down my thoughts.
On my port of CapIDL to CapnProto - that is, using CapnProto to define all of the existing Coyotos IPC - I am currently trying to get some C tests working. These test my generated capnproto functions and types. With the clarity of hindsight, this project would have been a perfect candidate for test-driven development, and I think I just got too excited about making progress. I'll switch to TDD when I start generating Rust and other languages.
It is fairly slow going, difficult to focus on because it feels quite disconnected from where I want to be going. I still think it will be worth it, though. I am not sure how I want to license the project, since it must work with coyotos headers I need to either incorporate some coyotos source or completely rework those edges. Maybe I should just make it all gpl2+.
There were questions on doing capnproto without a heap; the way this works in this implementation is that if you try to allocate a list or struct that doesn't fit, you'll be given a "null struct". You can ignore this and continue working with it, but the better practice is to query if it's the null struct every time you allocate. We can make this an error in other languages.
On capimg - the state I left it in, it could generate disk images identical to the Coyotos' mkimage program. I haven't put any further effort into making it build seL4 images. There are a bunch of concepts in microkit that need to be translated over, and there's no dynamic spacebank implementation for seL4, although capimg could be useful even for static images.
On async - I've come back around to thinking that I might start implementing the objects I had planned in userspace first. It wouldn't be as efficient, but the objects themselves would be much more useful. The objects I had planned had limited stack space, for commands, data and capabilities. In userspace, these objects could be as large as they need to be. Not to mention, building all of the factories required to make this part of the TCB means I think I can do revocation of mappings safely. In userspace, there is room to play with different interfaces for some of these objects, including supporting the io_uring ABI and maybe something closer to CapTP. There's room for several different interfaces, I think. That also makes these easier to port to seL4.
Since this is all in userspace, I should also be able to go back to the pure Coyotos ABI rather than its own... thing.
So - that's where my work is. Is it worth discussing this stuff? Should I move it to its own group? Any other thoughts?
--
William ML Leslie
Valerio Bellizzomi
Aug 26, 2026, 3:12:37 PMAug 26
to cap-talk
Sure it is worth.
Reply all
Reply to author
Forward
0 new messages