avsm changed the topic of #mirage to: mirage 2 released! party on!
betheynyx has joined #mirage
agarwal1975 has joined #mirage
mcclurmc has quit [Ping timeout: 260 seconds]
mcclurmc has joined #mirage
jermar has joined #mirage
brson has quit [Ping timeout: 260 seconds]
mcclurmc has quit [Ping timeout: 256 seconds]
noddy has quit [Ping timeout: 252 seconds]
brson has joined #mirage
noddy has joined #mirage
jermar has quit [Ping timeout: 246 seconds]
brson has quit [Quit: leaving]
AltGr has joined #mirage
jermar has joined #mirage
mort___ has joined #mirage
mort___ has left #mirage [#mirage]
lars_kurth has joined #mirage
mato1 has joined #mirage
wxfdglm has joined #mirage
<hannes>
mato1: sorry for opening lots of PRs ;)
<mato1>
hannes: :)
<hannes>
mato1: in console-solo5, I took the freedom to remove the unnecessary dependency on mirage-console (which dragged in a whole lot of stuff)
<mato1>
yes, that's great, i'm not sure why that stuck around
<hannes>
I tested on solo5-virtio-bhyve with success
<mato1>
afaik avsm wanted to keep it for some reason
<mato1>
(probably since moot)
<mato1>
ack, testing on ukvm now
<hannes>
no no, the console protocol is defined in mirage-types(.lwt), the only thing required is a `connect : string -> ...`.. in addition to that interface
<mato1>
hm, opam wants to downgrade ocb-stubblr from dev~mirage to 0.1.0 and cpuid the same, does that seem reasonable?
<hannes>
yes, pqwy released those to opam-repo (maybe you need to run opam update?) and removed from mirage-dev
<mato1>
yeah, i did update everything, just checking that this is intended
<hannes>
it is
<hannes>
(food)
<mato1>
(me too)
noddy has quit [Ping timeout: 245 seconds]
noddy has joined #mirage
agarwal1975 has quit [Quit: agarwal1975]
<hannes>
mato1: there's another minor PR https://github.com/mirage/mirage-solo5/pull/14 -- which is already in mirage-dev (and is pretty safe to merge, but I hate to click on the button myself ;)
<mato1>
what exactly does a dependency marked {build} do?
<mato1>
(i understand it means "needed for build", but how is it different to a normal dependency)?
<hannes>
{build} says it is required for building only, but not at runtime... this is primarily of use when updating dependencies: if in our package foo, x is marked as build dependency, and there's a new version of x, foo doesn't need to be reinstalled (afaiu)
<mato1>
2) nocrypto pulls in mirage-os-shim, which pulls in mirage-unix (and a bunch of other stuff)
<hannes>
mirage-clock-freestanding would be what I want...
<mato1>
ok, i'll have a crack at doing it. the C symbols are not really a problem, they're the same for mirage-platform (xen), for solo5 provided by ocaml-freestanding
<hannes>
2) I agree mirage-unix should be a depopt there
<hannes>
mato1: mirage-clock would be the name of choice if it would be xen/solo5 _and_ unix, but for unix there's a disjoint implementation
copy` has joined #mirage
mort___ has joined #mirage
<mato1>
looking at both implementations, not sure i want to try and unify them right now
<mato1>
it should be possible, but might need adding some C code (moving the tz handling stuff from Ocaml to a C function)
<mato1>
so that the freestanding version can just return "0"
fgimenez has joined #mirage
fgimenez has quit [Changing host]
fgimenez has joined #mirage
mort___ has quit [Quit: Leaving.]
rgrinberg has joined #mirage
rgrinberg has quit [Remote host closed the connection]
<hannes>
mato1: moving bits from OCaml to C is not anything I usually appreciate ;)
<hannes>
there's also no need to make them uniform
yomimono has joined #mirage
mort___ has joined #mirage
rgrinberg has joined #mirage
rgrinberg has quit [Client Quit]
agarwal1975 has joined #mirage
mcclurmc has joined #mirage
<ptrf>
20
<ptrf>
oops
mort___ has quit [Quit: Leaving.]
gjaldon has joined #mirage
mort___ has joined #mirage
gjaldon has quit [Remote host closed the connection]
noddy has quit [Ping timeout: 250 seconds]
<mato1>
so. i'm trying to port mirage-solo5 to topkg + ocb_stubblr. after adding the Ocb_stubblr dispatch bits to myocamlbuild.ml pkg/pkg.ml build complains about "
wxfdglm has quit [Quit: leaving]
<mato1>
(...) Unbound module Ocb_stubblr when trying to build the ocamlbuild plugin.
<mato1>
I don't understand why it's complaining (I'
<mato1>
m just copying bits using mirage-entropy/mirage-console-solo5 as a template.
<yomimono>
you might need to add the ocb-stubblr dependencies to _tags and pkg/META ?
<mato1>
i thought of that, but mirage-entropy doesn't do that
<yomimono>
hm, indeed. other than "make sure you have it installed" I don't have much useful advice, sorry :( might try @ing david elsewhere, looks like he doesn't have a bouncer here
rgrinberg has joined #mirage
mort___ has quit [Quit: Leaving.]
arthurgleckler has joined #mirage
noddy has joined #mirage
<yomimono>
removing the `let _ = STACK.listen` in stackv4 `connect` turns out to have some pretty annoying implications
<yomimono>
every user of a `STACK.t` probably shouldn't have to manually call listen before doing anything
<yomimono>
so I think I'm going to start the listening thread in `STACK.connect`, but keep a reference to it in the record and try to track it properly in some idiomatic lwt way
<yomimono>
^ hannes: I think you mentioned caring about this
<hannes>
yomimono: yes. every user of STACK should call listen. I think this is sensible. I don't think spawning background tasks is very sensible tbh.
<yomimono>
it's a bit messy because there's no way for something that gets the stack record passed as an argument to know whether listen's already been called on it
<yomimono>
so in practice, everyone has to do it to make sure the lower-level layers are are responding
<hannes>
yomimono: if you're not a unikernel (or an application), it has not been called unless you called it?
<yomimono>
if you're conduit, you got passed a stack that someone else might be doing stuff with
<yomimono>
you might be a library
<yomimono>
(conduit, resolver, http...)
<hannes>
yes... that's kind of strange... also listen is supposed to be called once.. and in the unikernel you don't necessarily have the stack in your hand?
<yomimono>
unfortunately no, you might have a CONDUIT and CONDUIT.t instead
<yomimono>
so conduit then has to handle this for you
<hannes>
maybe the old behaviour was ok for now, and we should dig down this rabbit hole another time
<hannes>
i put it on the list "why hannes doesn't believe in conduit" for now ;)
<yomimono>
I'd at least like not to reimplement it with the `let _ = do_a_thing`, that seems like a bad idea
<hannes>
and I thought in the end there should only be a netif.listen called... I don't understand what stack.listen does, apart from netif.listen..
<yomimono>
it constructs some stuff to feed to netif.listen, basically
mort___ has joined #mirage
<yomimono>
and subsequent calls to it will swap out the netif listener, which is very nonobvious
<hannes>
ah. oh. ah. uh.
<yomimono>
well, maybe it's obvious, I don't know
mort___1 has joined #mirage
<mato1>
yomimono: hannes: WYHAM, could you take a look at this WIP:
<yomimono>
but that's why the initial setup with an automatic call to listen worked -- in the hashtables provided for tcp and udp there are nothing because the user hasn't yet been able to call them, not yet having a stack record to pass as an argument
<hannes>
that pile of code... I don't have answers, sorry... maybe `let _ = doit ()` is the way to go for MirageOS3
<yomimono>
hm, ok
<yomimono>
thanks for thinking about it, anyway :)
<yomimono>
mato: looking now :)
<mato1>
it almost works, couple of things I couldn't figure out: 1) how to get the mirage-solo5 lib/ bits into the 'OS' module/namespace/whateveritis
<mato1>
2) topkg/ocamlbuild did not want to build lib/mM.ml, presumably due to missing .mli?
<mato1>
3) not sure what to do now about mirage-solo5.pc, it's possible it can go away altogether, though I'm still not clear on how the build system will figure out it's supposed to link in libmirage-solo5_stubs.a
mort___ has quit [Ping timeout: 256 seconds]
<mato1>
(lib/native/*.sh and lib/native/Makefile will go away, they're not used)
<mato1>
also, should I call the clib something else? It contains a few more bits than just "C stubs" (main.c mostly)
<poka>
9
<yomimono>
mato: I have the somewhat useless response that the current name looks real ugly to me, but I'm not sure what to rename it
<mato1>
yomimono: don't I have to call it 'OS.mllib' for the imports to work right?
* mato1
does not quite grok how this stuff works
<yomimono>
mato1: you can tell ocamlbuild to pull all of the libraries together into one module -- nocrypto does this with topkg
<yomimono>
that's what `packfile` is
<yomimono>
generally it's deprecated but nice for when you don't want to redesign everything
<yomimono>
the nicer thing to do is actually make a top-level OS module with the other modules under it
<mato1>
ok. the clib can be called libmirage-solo5_bindings.clib, that's more or less what the non-topkg version is called
<yomimono>
(I'm a noob about the build system too, hannes or dbuenzli or noddy are all better resources than me)
<yomimono>
(or samoht or avsm)
<yomimono>
(basically everyone :P)
<yomimono>
re: mM, giving it an mli does indeed help it build, but there's also a _tags annotation you can add that lets it build without one I think
<hannes>
since I didn't package anything with C and topkg and mirage yet, I don't have answers atm. the mllib contains a list of modules part of that library, thus mM should be in there, and you should have a mM.mli.