<talex5>
If someone understands stubblr, would be good to get ocaml-uint updated to use it.
<talex5>
That's all from me.
<yomimono>
cool, thanks!
<hannes>
I'm not certain that ocaml-uint is a good solution. but then it's unclear which operations people have on numbers.
<talex5>
Yeah, that's just the library capnp is using currently. But none of them supports Mirage currently.
<hannes>
I saw in your release, you measured the binary size of your calc example -- which is now 17MB from previous 21MB... may I ask why this is so big? (i.e. what contributes to its size the most?)
<talex5>
Haven't checked, sorry.
<talex5>
Didn't you have a tool for that at one point?
<hannes>
I was surprised and afraid to have such a big binary for such a little system (canopy is ~6MB stripped)
<talex5>
The only obvious big-ish thing in there is tls, so I don't know why either.
<yomimono>
talex5: solo5 targets should work too, right?
<talex5>
Should do.
<yomimono>
Cool :)
<yomimono>
If folks are looking for a fun project to try, a unikernel-unikernel comms demo would be neat
<yomimono>
I would like/subscribe/share/tweet/reblog/hype anyway ;)
<yomimono>
if that's all on capnp-rpc, I had a short update also
<hannes>
talex5: tls is maybe 1MB, not sure if this counts as "obvious biggish"
djwillia has joined #mirage
<talex5>
(strip might shrink a few MB from the current size too)
<kensan>
talex5: Sorry, I do not know anything about capnp-rpc: should it also work via shared memory as communication channel or are there some restrictions?
talex5 has quit [Quit: Leaving]
talex5 has joined #mirage
<talex5>
kensan: you'd have to write your own transport, but it might work.
<kensan>
talex5: The scenario I am imagining is two MirageOS unikernels on Solo5/Muen which could communicate via capnp-rpc.
<talex5>
The library doesn't worry too much about messages getting overwritten after it starts processing them though.
<talex5>
If you can lock the pages after exchange, that would be fine.
<talex5>
If you really care about performance, you might want to use raw capnp messages (without the RPC layer).
<kensan>
talex5: Ok, do you have a pointer regarding capnp and the currently available transports?
<talex5>
You just allocate some memory and build up a message in it. How you transfer it is up to you.
<kensan>
talex5: Right, sounds simple enough ;) Thanks for the info.
<yomimono>
so there's just one other thing on the agenda
<yomimono>
last meeting I got no objections to transfering mirage-nat into the mirage org and releasing it, so I did that
<yomimono>
feel free to use it for your ipv4 masquerading needs :)
<yomimono>
that's it!
<talex5>
Yay! I hope to update qubes-firewall for this soon!
<yomimono>
(oh wait - thanks hannes and talex5 for comments on it :) )
<yomimono>
talex5: speaking of qubes-firewall, it would be great to get a fix for the mirage-net-xen issue that's preventing it from working with HVM guests
<yomimono>
I keep meaning to look into it but it's easier to mean to do things than do them :/
<yomimono>
also I'm not so familiar with that bit of code
<talex5>
Yeah. I need to get a test VM set up to reproduce the problem.
<yomimono>
I'll send you a PR for mirage-nat 1.0 in qubes-firewall if that'll make it easier to find time ;)
<yomimono>
that's it for the agenda I think, any other business?
<talex5>
mirage-net-xen needs to implement the shutdown protocol that minios is expecting.
<talex5>
Fun starter project for someone... maybe?
<hannes>
in the name of haesbaert, he is now able to serve connections to his ssh server https://github.com/haesbaert/awa-ssh (according to his twitter account which includes a screencast)
<yomimono>
that's really cool!
<talex5>
Very nice!
<hannes>
speaking of potential projects: it came across my mind that a alcotest which generates a unikernel that runs the testsuite there would be tremendously useful
<hannes>
esp. if you handle c bindings etc., it's usually a nice indication when the testsuite compiles + runs on "bare metal" as well..
<yomimono>
that never occurred to me, but yes!
<hannes>
maybe i should put that onto canopy..
<yomimono>
there are a lot of awkward mock modules floating around to fulfill the mirage module types for test code
<yomimono>
they'd be less awkward if actually provided/assembled by something that's functoria-aware, maybe
<yomimono>
hannes: yes, I think that would be great :D
<hannes>
yomimono: i was primarily imaging pure test code...
<yomimono>
oh, I see. do you really need much cooperation from the testing library in that case?
<hannes>
hopefully not, it should be pretty generic :)
<yomimono>
it seems you could drop unikernel scaffolding around it (if the tests have some convention around naming)
<yomimono>
and then build that with CI tooling
<hannes>
that's where i think that alcotest needs some small extension
<yomimono>
I see. I think that would be valuable
<hannes>
(might be only myself who keeps on doing such things locally after working a bit on a specific library... most recently zarith updates)
mort___ has quit [Quit: Leaving.]
<yomimono>
those got merged recently! \o/
<yomimono>
if there's no other business...
<hannes>
yes, which brings us (on linux x86) towards non-executable stacks! :)
<yomimono>
:D
<mato>
i was meaning to ask what the relationship between the zarith updates and nx stacks was, but unfortunately i have to leave now, so another time
<hannes>
mato: zarith contains inline assembly, and didn't -Wa -noexecstack until 1.6
<mato>
ah ok
<hannes>
(or the ".section .note.GNU-stack,"",@progbits" in the .S)