<miragebot>
[mirage] hannesm deleted revert-623-minor at 62f7beb: https://git.io/vPSlB
miragebot has left #mirage [#mirage]
mort___ has quit [Quit: Leaving.]
yomimono has joined #mirage
mort___ has joined #mirage
mort___ has quit [Client Quit]
mort___ has joined #mirage
mort___ has quit [Quit: Leaving.]
Meeh has quit [Read error: Connection reset by peer]
Meeh_ has joined #mirage
AltGr has left #mirage [#mirage]
rgrinberg has joined #mirage
mort___ has joined #mirage
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
<mato>
hannes: Given that VAR?=value doesn't do what we thought it did, I guess I should replace it with VAR=value in the various Solo5/ocaml-freestanding Makefiles...? Otherwise some poor soul is going to go down a rabbit-hole if they try to edit values in Makefiles.
<hannes>
mato: it is not VAR?=value in the general case
<hannes>
but a limited set of defined vars, such as LD and CC
<hannes>
but yes, CC?=cc is pretty pointless afaics
<hannes>
I thought maybe we should have in mirage some LD = if $LD = ld then pkg-config ... else $LD to preserve user-settings
<mato>
yeah, those are the case(es) I was thinking of
<hannes>
the downside is that all the conditionals are GNU or BSD make specific... :/
<mato>
nah, if the user wants to override LD they can either do make LD=foo or edit the Makefile..
<hannes>
(I'd appreciate, what is not the case atm, the mirage generated Makefile to be BSD and GNU make compatible)
<mato>
hannes: actually, with the changes I made in #627 it's *almost* compatible -- the only thing left is:
<hannes>
for solo5, sure, every CC?= and LD?= _in Makefiles_ is pretty pointless (I also was not aware of this till 2 days ago)
<hannes>
you can get rid of it, since that build rule is now different
<hannes>
the CI as of now is in a state where a PR to mirage-dev rebuilds (successfully) mirage-skeleton... the mirage repo CI is a bit useless since it fails all over
<mato>
should I wait for mirage/mirage CI to complete? seems like there are some weird failures there...
<yomimono>
fedora hasn't passed in some time, but the others have been passing
<hannes>
mato: if you want to test it for sure, make a PR to mirage-dev with your custom mirage branch and wait for the results there (bonus: it build xen, unix, and both solo5 flavours)
<yomimono>
first off, we have an item from GemmaG: she's soliciting feedback about the mirage call/catchup and general mirage issues.
<mato>
\o/
<yomimono>
GemmaG, want to give us a bit more detail?
<GemmaG>
Yes hi! I'd really like to know what everyone finds valuable about the call/catchup just to make sure we are doing enough of those things
<GemmaG>
The form is anonymous so do be honest with feedback
<GemmaG>
If you have anything in more detail that you'd like to discuss in private, please feel free to contact me directly gg417@cl.cam.ac.uk or on slack
<avsm>
Thanks for sending that out! The debate over communications channels is an ongoing experiment: we've tried various video mechanisms, and chat, and are settling into the right cadence for what is most useful to us as we grow. Please be honest in your opinions on the form :)
<yomimono>
it's noted on the agenda also that the form closes on 24th October, so if you have anything you'd like to share, please do it soon!
<yomimono>
Anything else on this topic?
qli has joined #mirage
<yomimono>
Hearing nothing, let's move on:
<GemmaG>
Any further comments re. mirage communications are welcome either on the mailing list, or privately :)
<yomimono>
oh, sorry GemmaG!
<GemmaG>
np, all done :)
<avsm>
One thing I do note is that we don't preannounce the calls on the website, so I've had comments that publishing the schedule would be useful. I'll note that in my feedback form :-)
<avsm>
I'm slowly working on porting the Xen backend to ocaml-freestanding as well
<mato>
Long story short, ipaddr does not build on 4.04.0 due to ppx_optcomp not supporting the compiler
<avsm>
In my explorations, I discovered that openlibm is very old and broken on clang, so it really needs to be updated, but talex5 reports that all his changes made it upstream
<mato>
avsm: Um, openlibm in ocaml-freestanding *is* the upstream version, and works with clang fine
<avsm>
similar story for minios -- the upstream is now vastly different from our local fork, so we probably should rebase even though we use very little of the Xen minios
<avsm>
mato: I am referring to the Xen backend, which currently doesnt use ocaml-freestanding. The goal of my refresh is to make it use ocaml-freestanding so that Xen and KVM are on par in this regard. Xen currently uses a fork
<mato>
avsm: Right, but as part of that refresh you shouldn't have to deal with openlibm... or do you need that to build Mini-OS itself?
<avsm>
OCaml 4.04: Jeremie Diminio reports that he hopes to get a 4.04 compatible set of PPX extensions into OPAM in the next couple of weeks.
<yomimono>
That's excellent news.
<hannes>
would it be sensible to get rid of sexplib in ipaddr (or put it in a disjoint package)?
<avsm>
mato: I was checking as part of the refresh that there was no divergence in the Xen openlibm tag, and there appears to be very little
<avsm>
On the topic of ppx, I am very tempted to port to topkg and to pre-apply the ppx in the distribution tarball as a marshalled AST for particular compiler versions.
<avsm>
This would mean that stable package users would not need to have a working ppx setup, which in turn makes bleeding-edge compiler use easier
<avsm>
However, this might have unintended side effects such as source code locations changing. I'm not sure yet...
<hannes>
that'd be beneficial
<avsm>
Has anyone tried flambda? :)
<yomimono>
sadly I haven't
<avsm>
It's on my todo list, but I worry that we're missing some easy optimisations; could use a bit of time from someone on 4.03 playing around with the output. If you do have time, please report on the list :)
<yomimono>
A number of links on the agenda to mailing list threads (including a link back to the discussion on talex5's error proposals from 2015)
<yomimono>
hannesm proposes merging mirage/mirage#615 and iterating from there, if I understand correctly.
<avsm>
It sounds like there is a general desire to sort out the error API handling before Mirage3, despite delaying release a little
<avsm>
A beneficial side of the topkg refresh is that most of the porters have also been moderninsing library conventions, and Result handling is top of the list.
<hannes>
there's still some discussion about the signature of listen, but I consider this to be off-topic for 615.
<avsm>
We can depend on Result.t now, so we just need to pick the right combinators for Lwt/Result.
<hannes>
likely the function passed to listen should be able to return (unit, error) result... but unclear which error.. and `Msg of string should be used instead of `Unknown
<yomimono>
hannes: I have commits on top of your branch that will work just as well if your changes are merged, so it doesn't matter much to me
<avsm>
So at a minimum, it is uncontroversial to use "('a, [>`Msg of string]) Result.t", right?
<avsm>
the debate on the list is about whether the polymorphic variant should be more than just `Msg or not
<hannes>
this is multifold: 615 introduces for listen/write a (_, network_error) result Lwt.t. the network_error is outside of the module type, but in mirage-types, and a pp is provided by mirage-types
<hannes>
this means not all network implementations need to redefine the network_error type and a pp.
<avsm>
makes sense
* yomimono
nods
<hannes>
and once that is done, we can think about more
<hannes>
I don't think we can close the error type in any module type, since there are people using BLOCK natively, and others via a TCP connection over TLS... thus the error type there can be rather rich
<hannes>
but as dbuenzli said on the ML, maybe when we abstract values we should also abstract errors
<yomimono>
the inclusion pattern dbuenzli mentioned seems very natural to me
<mort___>
fwiw— i thought that the point made about errors not being any more or less special than non-error return values made sense
<avsm>
ok, so this adds actual code to mirage-types, but we are ok with that
<hannes>
another point of discussion is the device lifecycle (and disconnect, does anyone call disconnect?) I started on the mailing list with talex5 replying that we can simply use Lwt_switch.t
<mort___>
i think it makes sense as a way to let us make progress on this
<yomimono>
hannes: tcpip tests call disconnect a lot, but I've never used it in live code
<hannes>
yomimono: does it also call connect itself?
<yomimono>
hannes: yes, on the network provided by mirage-vnetif
<djs55>
I think when resources are implemented as file descriptors on Unix, it's good to be able to call `disconnect = Unix.close`
<hannes>
I think that for MirageOS devices, connect is generated by mirage, the tool, thus they're alive as long as the unikernel is alive
<yomimono>
the full lifecycle of the device is managed from within the test
<hannes>
yomimono: that's fine.
<hannes>
djs55: this is possible with providing a ?switch:Lwt_switch.t for connect as well, and switch it off once done
<djs55>
Would the switch replace `disconnect` or be another way to call it? Maybe I should go and read the thread
<hannes>
(I don't have any experience with this Lwt_switch.t thingy, but it looks like it may be useful.. anyways, no concrete proposal here)
<hannes>
djs55: replace afaics
<hannes>
djs55: you'll need to keep your Device.t and Lwt_switch.t around for its lifetime, instead of only the device.t.
<avsm>
Lwt_switch seems a very Lwt-specific solution, whereas having the Lwt-free version use disconnect is more useful in the future (e.g. for Async)
<avsm>
and the Lwt versions would then wrap disconnect in a Lwt_switch
jermar has quit [Ping timeout: 260 seconds]
jermar has joined #mirage
<yomimono>
anything further to say about this?
<yomimono>
please feel free to add to the mailing list thread as well :)
<yomimono>
hannesm, mato, and ricarkol have been doing a bunch of work to get freebsd support working nicely via bhyve
<avsm>
yay freebsd!
<yomimono>
not sure whether any of them want to talk about that further, but I thought it was worth mentioning because it's cool
<yomimono>
so thanks for your work on this :)
<yomimono>
last item listed is that the qubesos target pr is currently stalled because I'm distracted
<avsm>
this is really awesome. The maintainers of bhyve and Hyperkit (the osx fork of xhyve that exposes the hypervisor framework on the mac) have been talking recently about reducing diffs, so I hope that this will also help getting unikernels-on-macos running sooner
<yomimono>
:D
<mato>
for MacOS, there's also dan's uhvf work but afaict that's stalled at the moment for personal reasons
<mato>
otherwise, freebsd support is awesome, also because it's shaking out other bugs / cleanups
<yomimono>
mato: would more folks testing be helpful for you?
<mato>
btw, if there's anyone here with experience with virtio-type data structures who could help with ironing out bugs in the Solo5 virtio code, that would be wonderful. djs55 perhaps?
<avsm>
I have PV FreeBSD VMs on EC2, but sadly not much use for this
<mato>
yomimono: we have three separate people with test machines now (hannes, ricardo and myself), so i think we're fine there
<djs55>
I'm not a virtio expert unfortunately… more of a casual user, but I'd quite like to give it a go
<hannes>
or if anyone has time to implement virtio in OCaml, that'd be appreciated as well ;)
<djs55>
that's on my long term "I wish I had time to try that" list
<mato>
I'm just worried about the virtio stuff because I think we're making some obvious-with-experience synchronization mistake
<djs55>
justincormack and ijc_ are both pretty knowledgeable about virtio :)
<mato>
ah, good point, i'll ask ijc_
brson has joined #mirage
<mato>
(that's all from me on this topic for today ...)
<yomimono>
that's the end of our agenda!
<avsm>
AOB: any requests docs.mirage.io aside from matos?
<amirmc>
Yup
<thomasga>
is there an item for "MirageOS in space"?
<avsm>
(I'll add martin's comments about the docgen to it, but I've had a number of people just mention stuff to me privately and I'm losing track)
<avsm>
If you pile all of your requests on there,that will help.
<thomasga>
unfortunately I have not much to say on that topic, but I would be glad to hear anyone who has things to say about it :-)
<avsm>
GemmaG: have you also been looking into Merlin support?
<GemmaG>
indeed I have!
<avsm>
I'm not sure how many people in Mirage use Merlin, but might be worth opening a feedback tracking issue on this
<GemmaG>
I have got some great feedback from JS, Mirage and individuals using Merlin - I'm collecting it to pass onto Fred so he can work on a longer term roadmap
<avsm>
I'm keen to expose a global database of all the Mirage ecosystem cmt files and Merlin seems to be a key part on that
<thomasga>
would be useful to have an idea on which library needs porting to topkg
<thomasga>
to help with docs
<amirmc>
AoB item: Brief update on MirageOS 3 announcement activity. We've got a rough draft of a press release from Linux Foundation Folks and I've been in touch with Ericsson and IBM folks about getting quotes. I now have a quote from Ericsson and should have something from IBM at some point. I've mentioned to both that the release date is not defined yet. Depends on how the hacking goes.
<GemmaG>
Yeah re tracking, I will aggregate my notes and add an issue and talk with Fred
<hannes>
thomasga: cstruct. pls split out cstruct.unix and cstruct.lwt :)
<thomasga>
also, once we have all the docs, it will be useful to go other them and improve them/make them more consistent :-)
<thomasga>
(hint: I am happy to help in the topkg + doc effort)
<noddy>
so there is this problem with ocamlbuild and C stubs, which gets painfully obvious with topkg..
<avsm>
noddy: I have the start of an ocamlbuild plugin that does C stubs entirely from scratch instead of using the existing ocamlbuild rules
<noddy>
.. in that ocamlbuild lacks sufficient support for building C stubs sanely, and mirage libs with C play some more tricks.
<noddy>
but again, i'm rewriting the entire thing again. it works, but the approach is wrong.
gemma_ has joined #mirage
<avsm>
ooh pkg-config support
<avsm>
ok, lets coordinate on this on the devel list
<noddy>
avsm: what i'm working on now if adding rules for a new build target which preps stuff and then chains off to the built-in (shipped-with) .clib support
<noddy>
open-closed principle.
miragebot has joined #mirage
miragebot has left #mirage [#mirage]
<miragebot>
mirage/master 9889afa Martin Lucina: Use LD=(...) in generated Makefile
<miragebot>
mirage/master ee26a38 Martin Lucina: Remove XENLIB from generated Makefile...
<miragebot>
mirage/master 5a28986 Martin Lucina: Invoke pkg-config directly when generating Makefile...
<miragebot>
[mirage] yomimono pushed 4 new commits to master: https://git.io/vP9mP
<avsm>
I'm not too keen on depending on the .clib support; we might as well just call the CC directly rather than go through ocaml
amirmc has quit [Quit: Leaving.]
<hannes>
off to priscilla...
<noddy>
clib support is 10 lines of code. i prefer reusing their maintenance effort.
<avsm>
alright, lets chat about this on the devel list? I need to drop off now but will send an email later with an outline of the tcpip topkg fork which has some cstub rules as well
<avsm>
i think a combination of these plugins would work
<avsm>
dropping off now... thanks everyone!
<yomimono>
anything else, or shall we let unpurecamelbot take a nap?
<gemma_>
Ok all done 😊
<gemma_>
unpurecamelbot commit done
<unpurecamelbot>
done
<noddy>
ceterum, censeo carthaginem esse delendam?
<mato>
bye all...
<thomasga>
thanks all! bye
<gemma_>
unpurecamelbot bye
<yomimono>
thanks everyone!
unpurecamelbot has quit [Quit: unpurecamelbot]
thomasga has quit [Quit: Leaving.]
avsm has quit [Quit: Page closed]
jermar has quit [Ping timeout: 250 seconds]
copy` has joined #mirage
rgrinberg has quit [Remote host closed the connection]
mort___1 has joined #mirage
rgrinberg has joined #mirage
rgrinberg has quit [Client Quit]
mort___ has quit [Ping timeout: 250 seconds]
rgrinberg has joined #mirage
agarwal1975 has quit [Quit: agarwal1975]
mort___1 has quit [Quit: Leaving.]
qli has quit [Quit: Page closed]
jermar has joined #mirage
mort___ has joined #mirage
mort___ has quit [Client Quit]
mort___ has joined #mirage
gemma_ has quit [Quit: Connection closed for inactivity]
rgrinberg has quit [Ping timeout: 252 seconds]
andreas23 has joined #mirage
mort___ has quit [Ping timeout: 256 seconds]
<demonimin>
is mirage-skeleton/block broken for anyone else on mirage-dev on unix? sector_size should be the page size not 512
mort___ has joined #mirage
<yomimono>
demonimin: file an issue? I probably broke it but I've got my head in something else right now
<yomimono>
thanks for reporting :)
<demonimin>
done
<yomimono>
thanks!
agarwal1975 has joined #mirage
andreas231 has joined #mirage
yomimono has quit [Ping timeout: 250 seconds]
andreas23 has quit [Ping timeout: 244 seconds]
mort___ has quit [Quit: Leaving.]
yomimono has joined #mirage
yomimono has quit [Ping timeout: 256 seconds]
GemmaG has joined #mirage
GemmaG has left #mirage [#mirage]
rgrinberg has joined #mirage
rgrinberg has quit [Read error: Connection reset by peer]