<mato>
Shall I paste it here, or will everyone just go off and skim it?
<avsm>
reading it!
<yomimono>
that's a lot to paste, folks should go read it IMO
<avsm>
does openlibm not have an upstream aarch64 target?
<avsm>
thats surprising
<mato>
It has one, but the actual state of it is unclear.
<mato>
There have also been a few aarch64-related commits to master since the version we're on (0.5.4), so someone is doing something.
ricarkol has joined #mirage
mort___ has joined #mirage
<avsm>
interesting -- it would be good to not be the only user on aarch64 :)
<mort___>
.
<avsm>
great progress on arm64 though!
<dstolfa>
o/
<avsm>
hi mort___ ...
<mato>
kensan: One thing to keep in mind for you (from my status report) is that I'd like to merge the rest of the Muen bits after the API rework is done.
<mato>
kensan: So, it'll take a while yet, hope that's ok with you.
<Kensan>
mato: Sure thing, no hurry from my side.
<mato>
kensan: Oh, and thanks for hosting me on Friday, it was good to meet up in person!
<mato>
ricarkol: ...which updates on the state of the various works in progress. Also note I'll be on holiday for 2wks starting Friday.
<avsm>
ricarkol: someone who might be interested in this solo5 direction is phil estes at ibm too
<avsm>
he's been doing really good work on integrating other sandboxing features like user namespaces into software
<yomimono>
mato: I'm on holiday starting right when you get back, and probably not reliably reachable until 20th July, so probably best to coordinate with someone else for release if you think you'll be ready before then
<ricarkol>
Ah great, thanks for the pointer avsm.
<hannes>
what I miss from the report (thx for the report) is the state of Hypervisor.Framework + solo5!?
<mato>
hannes: That's up to Dan, I've not heard from him in a while. Maybe ricarkol knows?
<avsm>
coordinate with me for the release mato
<ricarkol>
Not sure if Dan is working on the Hypervisor.Framework + Solo5 PR. Will ping him.
<yomimono>
anything else on solo5?
<hannes>
ricarkol: thx. imho would be nice to have that rebased + merged into master..
<mato>
hannes: It needs more than just a rebase since afaict the last version is from before the multi-backend refactor.
<yomimono>
let's move on :) next up we had an item on jbuildering all the things from avsm and djs55
<mato>
yomimono: I think we can move on.
<yomimono>
mato: agreed :P
<yomimono>
also in this agenda item is a link to a mirage/mirage PR which I'd missed -- it's a bit unclear from the text alone exactly what the scope of these changes are, can someone elaborate?
<yomimono>
this PR changes the build system for mirage-types but not the mirage frontend tool, it seems?
<djs55>
I think we've jbuildered quite a lot of things now. I think avsm is going to take a look at mirage-platform, whose build is quite complicated.
<djs55>
while doing the jbuildering we took the opportunity to remove more depexts, which led to some package refactoring e.g. io-page-unix now exists
<avsm>
essentially the mirage/mirage PR is demonstrating the workflow
<djs55>
I believe it's possible to use "opam source" to grab lots of library sources and then use "jbuilder" in the root for a concurrent build of everything
<avsm>
its not a complete port yet -- functoria and the CLI tool also need porting (quite easy, just not done yet)
<djs55>
I'm not totally sure what the best-practice is these days for doc generation — the question came up on the functoria jbuilder PR
<avsm>
but the PR demonstrates the cool productivity gains: you just clone a bunch of related repositories, and they are automatically built in the right order and incrementally. This is an awesome way to revise an interface in mirage-types, build all the dependents, and then cut individual opam releases
<avsm>
but the progress in the past few weeks is that we've ported 20+ libraries to jbuilder, and also found several inconsistencies while removing boilerplate (e.g. in manual META files)
<avsm>
so i think this is a very very good direction -- but its a good time for others to also get involved and express opinions on the mirage/mirage PR -- most particularly, express any blocking problems now
<avsm>
i would like to migrate docs.mirage.io to be a purely jbuilder build in the next couple of weeks -- in this scheme, the doc generation takes ~1-2 minutes _vs_ the 40 minute (!) build time it is now.
<hannes>
I've seen lots of CI failures where PRs got merged... is this travis CI now considered obsolete and merging even with CI errors is considered ok?
<avsm>
there are some mega PRs coming in from conduit, cohttp, dns and tcpip
<avsm>
hannes: nope, I've been fixing CI whereever Ive spotted errors
<djs55>
all the debian CI builds are failing on travis since the recent debian release
<avsm>
the cstruct one is an infra failure for fedora (also upstream flaky atm): system-python: /builddir/build/BUILD/hawkey-0.6.4/src/sack.c:354: load_ext: Assertion `ret == 0' failed.
<avsm>
and the mirage/mirage one is travis failing on all jobs
<avsm>
so overall we are in pretty good shape with travis -- but its getting overwhelmed by the number of repos we have
<avsm>
all the jbuildered packages that have been refreshed should be green now
<avsm>
and we just need a freebsd build bot -- ive got a machine now,so will setup surf build in the short term when i get a chance
<hannes>
avsm: good to hear! thanks to djs, samoht and avsm for the jbuilder porting!!!
<djs55>
I've found the ocaml/opam-repository CI to be good — the revdeps testing highlights lots of interesting things.
<djs55>
sorry for the disruption it has caused! hopefully we're passed the worst of that
<avsm>
yeah and posting on discuss.ocaml.org is pretty useful with breaking changes
<Drup>
avsm: do you intend to also port mirage's generated build system too ?
<avsm>
drup: yes once the rest has settled
<avsm>
we should be able to just `jbuilder build` instead of `mirage build` -- jeremie is happy to add an output-obj rule (there is a PR on jbuilder)
<yomimono>
anything else on jbuilder?
<hannes>
well... the mirage build is rather tricky, I bet jbuilder is (not yet!?) ready for that.. e.g. on the functoria PR djs mentioned that dontlink is not supported, which is crucial for MirageOS unikernels..
<mort___>
(to save updating all the instructions again, perhaps `mirage build` could invoke jbuilder rather than the user doing it?)
<avsm>
hannes: we were just chatting about stubs and dontlink ... I think we need to clean up that whole affair
argent_smith1 has joined #mirage
<avsm>
and specifically dontlink should not be vital -- it can be done at the very end link rather than in every library
<yomimono>
avsm: is there a document with a roadmap of expected next actions related to this somewhere?
<yomimono>
or a roadmap at all really
<avsm>
yomimono: nope, but there should be #818 i think was my attempt but i havent had the bandwidth to keep it fully updated
<yomimono>
aha, yes, that's what I faintly remembered
<avsm>
ill rectify that...
<avsm>
part of this was us convincing ourselves that jbuilder was a worthy replacement before committing to it. and then the floodgates opened up and hundreds of ports came flying in and we got bowled over
<hannes>
avsm: I'm talking about the fringe of a MirageOS unikernel above. it is not needed for functoria-runtime or mirage-runtime AFAIK... I guess a proper solution for cross compilation is what is needed for MirageOS unikernels (I talked a bit with dbuenzli about that)
<yomimono>
some conversation either there or on mirageos-devel about "clean[ing] up that whole affair" would be great, instead of just getting the PR one day
<yomimono>
:)
<avsm>
hannes: yeah. the good thing is that jbuilder supports cross compilation with workspaces, so need to figure that out
<hannes>
yomimono: +1
<avsm>
yomimono: yes indeed, completely agreed. there have been various discussions on mirage-platform about the issue with hannes djs55, but scattered as usual
<mato>
+1 for long-form discussion on cross-compilation
argent_smith has quit [Ping timeout: 260 seconds]
<avsm>
before we can get to that though, it would be _very useful_ to get some opinions on the basics of jbuilder
<avsm>
it will be difficult to move to another system, so objections late in the port will not be helpful :)
<hannes>
avsm: that sounds great. a document about how a unikernel should be compiled would be rather useful (before deciding that jbuilder is mature enough to do so)...
<avsm>
once we've got mirage/mirage ported to it, then we can start depending on some of its more advanced features
<avsm>
hannes: yeah -- step 1) is how ocaml should be compiled (which we are doing now and almost done) and step 2) is the C linkage model we want
<avsm>
i think i might kick this discussion off on discuss.ocaml.org - i'm liking it for long form discussions
<hannes>
I personally would also be in favour to use an opam switch for cross-compilation to get rid of zarith-xen / foobar-xen / foobar-freestanding packages...
<avsm>
hannes: yes!!!!
<hannes>
(this is not real cross-compilation, not talking about compiling your arm unikernel on your x86 host)
<mato>
One thing to note is that having "real" cross compilation may imply having a "real" C cross-compiler around.
mort___ has left #mirage [#mirage]
<demonimin>
(I was surprised to see my jbuilder-built stublib work on first try with a mirage tool-built unikernel — that was nice)
<avsm>
hurrah demonimin :-)
<mato>
hannes: Ah, we mean different things by "real" cross-compilation. The current approach (for most host/build OSes) does not do a "real" cross build but can work without having a full cross (fsvo) toolchain installed. "Cleaning that up" may require moving to a full cross toolchain.
mort___ has joined #mirage
<avsm>
lets talk about this more longform...probably too long for this irc meeting
<mato>
Yup
<yomimono>
OK, let's move on then
<yomimono>
talex5 had a bit to share about capnp-rpc
<yomimono>
this says "fuzzing" in it so let's definitely hear about it :D
<talex5>
Have been doing lots of AFL fuzzing.
<talex5>
I'm hoping AFL can discover all the TODOs in the code...
<talex5>
that would give me some confidence the tests are covering lots of cases.
<talex5>
Anyway, it seems reasonably stable in its current form, though lots left to do:
<TImada>
I implemented packet handling optimization in the host OS side by using Netmap as shown in the page 2.
<yomimono>
for a *very* nice performance improvement, I see!
<TImada>
This optimaization targets only packet sending.
<avsm>
this is a very very good update TImada. netmap looks like a big win!
thomasga has joined #mirage
<hannes>
TImada: is your modified solo5 code available?
<TImada>
and includes VMExits overhead coming with data storing operation.
<mato>
TImada: Can you summarize in 2 sentences what netmap "needs" from Solo5/ukvm to run in the "queued" mode you describe in the PDF?
<TImada>
haness: Yes, but it requires a tricky procedure to use ..., sorry. I need to write a readme file.
<mato>
TImada: Is it essentially just a memory region mapped from the host, or something more than that?
<TImada>
mato: memory mapping would be enough.
<TImada>
I have already finished testing memory mapping of Netmap ring buffers.
<mato>
TImada: How does the guest get woken up if it's polling/sleeping inside the monitor (ukvm)?
<mato>
TImada: Does netmap provide a fd or something you can poll() on the host side?
mort___ has quit [Quit: Leaving.]
thomasga has left #mirage [#mirage]
<TImada>
mato: Yes, Netmap provides a fd for poll() like functions. The current implementation uses ppoll() similaly.
<mato>
TImada: excellent. that's what I needed to know. thanks.
<yomimono>
great! :) anything else on this, TImada?
<mato>
So it's basically poll() for notifications/slow path and shared memory for the fast path.
<TImada>
Currently, I'm implementing ring buffer manipulation functionality in the guest OS layer to reduce the VMExits overhead. That's all from me.
<TImada>
mato: Yes!
<yomimono>
sorry, I'm lagging badly, perhaps self-governance for the last 5 minutes of the call :)
<yomimono>
next up was g2p (denominin here I think?) on wodan
<demonimin>
Hi! I've fixed many bugs, so it's a good time for a status update
<demonimin>
I was looking into performance improvements, but hit some bugs in alternative Map implementations. Speak up if you know a good Map-like struct.
<avsm>
as context: wodan is demonimin's pure ocaml filesystem bases on hitchhiker trees and optimised for flash
<demonimin>
currently I fill a 16Mb filesystem in 2s which isn't impressive, but most of it is in-memory bookkeeping.
<demonimin>
after that I'd like to serve as an Irmin backend, which will require forward-porting irmin-chunk to current Irmin APIs
<avsm>
i'd be happy with a slow and rock solid first implementation
<avsm>
great to see AFL fuzzing in there from the start, just like with capnproto
<demonimin>
yes. fuzzing is hard to do because of the large state space (512b sectors is the minimum), and it hasn't uncovered any bugs.
<demonimin>
The new url is https://github.com/g2p/wodan, if you want to try it, see runner/unikernel.ml for an example
mort___ has joined #mirage
<demonimin>
Well, that's it I think. There's still some features to add, and possibly one or two format changes.
<talex5>
How are you fuzzing it? By feeding it random structures, or random operations?
<mato>
demonimin: Does it run on Mirage/Solo5?
<demonimin>
it does
<mato>
Cool. I'll try it.
<demonimin>
I feed it a prepared image, modified by AFL, and do one more insert on it
<demonimin>
I also do random operations on it without afl, which has been fruitful
<mato>
yomimono: By the way, there are lots of interesting updates today, can the logs be (at least) copy/pasted somewhere pointed to from the Wiki?
<avsm>
this is awesome -- i wonder what a direct capnproto -> filesystem would look like
<yomimono>
mato: yes, we can manually put them into canopy and add a link
<hannes>
(since we're running at the end, I'd like to mention two things: a) in several issues/PRs we discussed error behaviour (e.g. netif.write with buffers bigger than MTU; block write with non-aligned offsets, ...) -- can we somehow document these behaviours at the interface level (do we want to have common behaviour also for errors?)) -- b) how long does it take to extract a zone file from ghandi (to run our own)? https://github.com/mirage/ns.mirage.io/issues/1
<hannes>
(so far 2 months)
<yomimono>
in the absence of our dear imaginaryfriend
<avsm>
mato: yomimono any chance of a quick issue on mirage-www -- djs55 and i are fixing the build
<demonimin>
a redis/memcache-like would be cool
<avsm>
sorry hannes, its only ever brought up on these calls when i dont have access. doesnt get on my todo list properly. I'm emailing myself now...
<mato>
avsm: issue on mirage-www for what?
<reynir>
I'm tempted to make an IRC bot for reminding people (me) when the meeting is about to start
<avsm>
the irc logs, need to modify code slightly to have an option to link to whitequarks summaries
<yomimono>
reynir: please do :)
<avsm>
reynir: yeah!
<avsm>
unibactrian
<avsm>
a one humped camel bot
<hannes>
(another instance of non-symmetric behaviour seems to be flow.write (and esp. console.write))...
<reynir>
Heh
<yomimono>
hannes: it's true that underspecified error behavior is a problem currently and will get worse as we have more implementations of common signatures
<avsm>
gotta run -- but specifying the invariants in the mirage-types seems like the right direction
<avsm>
thanks all!
<yomimono>
both documentation and testing seem like important ways to deal with that
<yomimono>
here's the contract, here's how we know that this implementation meets it
<hannes>
yomimono: a compliance test suite for a given interface X would be great to have, yes! :D
<yomimono>
I started trying to do this for mirage-fs some time ago but got bogged down badly pretty quickly
<djs55>
IIRC mirage-block has a functor which passes through requests after checking alignment etc. I don't think it's used anywhere yet
<yomimono>
(coupon is good for several green github squares)
<yomimono>
djs55: interesting; did it come from some other implementation that was using it for testing?
<yomimono>
(IIRC all the mirage-block stuff was pulled together from common code in many block libraries during 3.0 migration? or possibly I'm misremembering)
<djs55>
I think it was an experiment that was never completed
avsm has quit [Ping timeout: 260 seconds]
<djs55>
It's called `mirage_block_safe` but it has no users
<yomimono>
ah yes, I remember this now -- specifically I remember thinking "what is this, it has no users"
<djs55>
I see it every now and then and it reminds me that we don't check alignment properly :)
<hannes>
(to drop in https://github.com/mirage/mirage-flow/issues/4 is the FLOW.write behaviour which looks non-uniform, also in solo5 I think the resolution is that Console.write may do a partial write)..
talex5 has quit [Quit: Leaving]
<mato>
hannes: The Console case is (IMHO) a red herring -- at the Solo5 level I see no point in reporting that a partial write happened.
<mato>
hannes: So I guess, if you want to be pedantic, the Solo5 documentation can mention that you could get a partial write in which case the data will just be discarded.
<mato>
But I don't see what else can be done.
<yomimono>
I think the general issue is valid though; we have poorly-defined and inconsistent semantics for some important primitives which should be the same across implementations
<hannes>
mato: I agree. and would lobby to revert this "console is a flow"... while the interface is similar, there's no support for read on console, and write may be partial.
<hannes>
mato: (just to prevent anyone from trying to use a console as a flow and get reliable data transfer)
<mato>
hannes: I've not looked into the Mirage Flow semantics in detail, so I don't have any huge opinion on that.
<yomimono>
I think "console is a flow" is extremely misleading
<yomimono>
but I think that's enough me-too'ing from here
<mato>
Anyhow, what I'm trying to do for the Solo5 C APIs in #200 and related is in a similar vein -- document and enforce the various edge and failure cases.
TImada has quit [Ping timeout: 260 seconds]
<mato>
...and eliminate undefined behaviour, with some preference to cutting "scope" from an API if it makes sense.
<mato>
e.g. L2 network I/O insists that you deal in whole packets only, Block I/O insists on whole blocks, etc.
<hannes>
mato: I appreciate and support your #201! I just try to raise some awareness of missing documentation and maybe not everything where some types match should be the same interface :)
<mato>
+1
<hannes>
(in the hope that someone will be bored enough to do something about it)
yomimono has quit [Ping timeout: 240 seconds]
ricarkol has quit [Ping timeout: 260 seconds]
yomimono has joined #mirage
copy_ has joined #mirage
yegods has joined #mirage
yomimono has quit [Ping timeout: 240 seconds]
yomimono has joined #mirage
mort___ has quit [Ping timeout: 268 seconds]
yegods has quit [Remote host closed the connection]
yomimono has quit [Quit: Ex-Chat]
yegods has joined #mirage
argent_smith1 has quit [Ping timeout: 240 seconds]
argent_smith has joined #mirage
yegods has quit [Remote host closed the connection]
yegods has joined #mirage
argent_smith has quit [Ping timeout: 240 seconds]
argent_smith has joined #mirage
mato has quit [Quit: WeeChat 1.7.1]
yegods has quit [Remote host closed the connection]
yegods has joined #mirage
yegods has quit [Remote host closed the connection]
yegods has joined #mirage
yegods has quit [Ping timeout: 240 seconds]
yegods has joined #mirage
yegods has quit [Remote host closed the connection]
yegods has joined #mirage
yegods has quit [Ping timeout: 276 seconds]
yegods has joined #mirage
argent_smith has quit [Quit: Leaving.]
AltGr has left #mirage [#mirage]
yegods has quit [Remote host closed the connection]