<mato>
hannes: took some time yesterday to figure that one out :)
<mato>
^7heo: we know, i'll ping avsm about it
<^7heo>
mato: ok :)
<^7heo>
Laters then :)
<^7heo>
o/
^7heo has left #mirage [#mirage]
<hannes>
mato: oh, sorry then
<mato>
hannes: no prob. if there's a better way to do the nmdm stuff lmk.
<hannes>
maybe what I meant is to use nmdm and only optionally connect to it (or have an option to not connect by default, e.g. use it as a startup rc.d script)
<fructase`>
hannes ?
fructase` is now known as fructase
<hannes>
(i.e. having the "cat ${TTYA}" conditionally)
fgimenez has quit [Ping timeout: 256 seconds]
fgimenez has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
mort___ has joined #mirage
demonimin has quit [Remote host closed the connection]
mort___ has quit [Quit: Leaving.]
rgrinberg has joined #mirage
demonimin has joined #mirage
agarwal1975 has joined #mirage
<mato>
hannes: ah, just saw the message here
<mato>
hannes: AFAICT nmdm doesn't work that way
<mato>
if you wanted a nmdm and no cat then bhyve would have to run on the 'A' end. however, if bhyve fails and exits then you lose the nmdm device altogether
yomimono has joined #mirage
<mato>
it's also not obvious how much buffering nmdm does
<hannes>
what happens if solo5 doesn't get a console device at all? atm only manager: connecting and manager:connected is printed there anyways (for me, that is, where all other logging is going via network to the syslog collector)
<hannes>
anyways, have to run off to a meeting...
<mato>
solo5 always assumes COM1 is available
<mato>
so it'll just send chars to it regardless
<mato>
also, a failure case is e.g. fatal trap. with the setup you describe (nmdm and no cat) you'll lose that info
fgimenez has quit [Ping timeout: 252 seconds]
<mato>
which is why i suggested that in a production deployment you always want the output to go somewhere (e.g. | logger, > file, or whatever)
fgimenez has joined #mirage
fgimenez has quit [Changing host]
fgimenez has joined #mirage
mort___ has joined #mirage
mort___1 has joined #mirage
mort___ has quit [Ping timeout: 245 seconds]
fructase has quit [Remote host closed the connection]
fructase` has joined #mirage
<reynir>
Call in 1½ hours?
<yomimono>
if I've done the timezone math properly, yes!
<reynir>
\o/
<reynir>
Yea, DST is a pain
<yomimono>
`TZ=Europe/London date` confirms it!
<yomimono>
I'm glad I live in a region where it unambiguously applies, at least
<yomimono>
loads of places where it's weird or different on a local scale; sounds like a complete nightmare
<yomimono>
worked somewhere that had machines in both these places and made the extremely misguided decision to use localtime on them :/
<reynir>
heh
<reynir>
At work we use localtime. Luckily the DST/timezone is not too crazy, but I would prefer UTC
<mato>
hannes: re solo5#112, are you sure you want nmdm-without-cat? As I wrote before, if the bhyve process terminates then you will lose any console output that might have been buffered up in the nmdm device...
<hannes>
mato: not for development, clearly. but once I deploy, I would be happy to not have a console at all ;)
<hannes>
mato: but you're right, maybe redirecting to a file is the way to go atm
<mato>
hannes: I'm fine with adding an option for "no console at all", it's the nmdm-without-cat case which I don't particularly want to implement
copy` has joined #mirage
<reynir>
Haha this is great - there's a group against DST which hold meetings last sunday in march between 2 am and 3 am (which doesn't exist because summer time)
<hannes>
mato: a headless case would be appreciated... as mentioned, with syslog there are only 2 messages on the console anyways (I'd be happy to not have a console at all in this case)
<mato>
hannes: Hmm. Not quite so simple as it seems. If I kill the serial device then Solo5 will hang trying to write to it (waiting for the non-existent U
<mato>
UART tx FIFO to come empty)
fructase` has quit [Remote host closed the connection]
<hannes>
can we fix that in solo5? ;)
<mato>
mhhhhm
<hannes>
(a "no" is acceptable, and I'm also fine with manually redirecting the cat to /var/log/myconsole (or /dev/null if I'm not interested))
<hannes>
it is not urgent, and likely not worth the effort
<mato>
yeah, let's leave this as it is for now
<hannes>
ack. sorry for bothering
<mato>
also, the primary goal of that script is to help dev/test/CI, "deployment" is just a bonus
fructase` has joined #mirage
fructase` has quit [Remote host closed the connection]
fgimenez has quit [Ping timeout: 260 seconds]
fgimenez has joined #mirage
GemmaG has joined #mirage
avsm has joined #mirage
bactrianbot has joined #mirage
<bactrianbot>
starting logging
<avsm>
hello bactrianbot!
<yomimono>
whoa, this is a new bot!
bactrianbot has quit [Remote host closed the connection]
<yomimono>
speaking of djwillia, first item on the agenda is status of solo5!
talex5 has joined #mirage
<djwillia>
(which djwillia is out of the loop on :) )
<yomimono>
mato, much to say about it? says here it's stable, let's release ;)
<mato>
:-) yeah, i put that in
noddy has quit [Ping timeout: 260 seconds]
<avsm>
So the first use I have for solo5 is for the UDP DNS server for mirage.io
<avsm>
how does everyone feel about switching the authoritative DNS over to a self-hosted one?
<hannes>
+1+!+!+1+!+!+1+!
<yomimono>
positive!
<avsm>
There may be short term website instability, but there's only way to shake out the bugs in the upcoming release...
<avsm>
ok, great! I've got infrastructure hacking on my todo list for Friday
<avsm>
so it'll be a Scaleway Solo5 DNS server on Solo5 by the end of the day I hope
* hannes
ordered a server to do solo5 deployments on
<avsm>
hannes: where?
<hannes>
(solo5/FreeBSD/bhyve that is)
<mato>
avsm +1 go for it, also we wanted some solo5 backends load balancing the HTTP/HTTPS site too
<hannes>
avsm: on the internet, physical server, will be hosted where the btc pinata is atm (which is a piece of hardware soon going off-service)
<avsm>
yeah I figured DNS would be a new service and then rotate into the existing HTTP/HTTPS pool
<mato>
avsm: I'd suggest just doing plain old simple DNS LB (e.g. resolve mirage.io to 3 A records, one for each backend)
<avsm>
yeah, that's the plan
<avsm>
a stretch goal is to have it clone its zone file from a GitHub Irmin backend
<avsm>
which should work, since Canopy does it
<avsm>
one concern I have about Solo5 is that it really has to become coinstallable, and I think that's becoming easier now
<mato>
So, yeah, yomimono asked. Solo5 is pretty stable, on ukvm and virtio. There are a few remaining things before release.
<avsm>
we have noddy's ocb-stubblr now, and I'm about to refresh my tcpip port to use it (along with a topkg port)
<avsm>
after yomimono stops shoving awesome features into tcpip that is ;-)
<mato>
1) coinstallability (since avsm just brought it up). avsm: Can you take this on?
<yomimono>
:P
<avsm>
mato: yes, I'm going to look at the stub part of it at least -- ocb-stubblr appears to have settled down now
<mato>
2) end-to-end CI (listed as a thing for 3.0 for ages). I'm not going to do this for the full Mirage stack, but am working on at least doing it for the Solo5 standalone (C) tests.
<hannes>
I suspect the zarith (+ maybe gmp) story needs to be sorted out (since zarith-* modify the zarith META file, which is unfortunate)
mort___1 has quit [Quit: Leaving.]
<avsm>
hannes: yeah, not looking forward to existing libraries :-/
<mato>
3) (mentioned on today's agenda) I was thinking of doing a "speculative" refresh of the Solo5 C interfaces.
<Drup>
(speaking of zarith, and this is completely off topic, it would be nice to move it to github under the "ocaml" umbrela ...)
<yomimono>
mato: can you elaborate on that? I don't know what it means exactly
<hannes>
since they emit different "lines" to the META file, maybe a "echo" and "grep -v" (to revert) can do the trick
<avsm>
Driup: no idea who maintains it I'm afraid
<Drup>
avsm: xavier leroy ?
<avsm>
mato: yomimono: I could also use some clarification on that
<avsm>
Drup: I'll ask him at the developers meeting in December, since it isnt urgent
<mato>
yomimono: Well, at the moment the interfaces are somewhat simplistic and we've known for ages that they will need changing for things like >1 network/disk support, etc.
<Drup>
avsm: last released was drafted by him, so yes, probably
<hannes>
+1 for >1 network device!
<Drup>
thanks
<yomimono>
mato: ah, I see. supporting >1 network/disk would be nice before release
<mato>
yomimono: So, what I'm thinking is that I can try and redesign the interfaces the way I'd like to see them (does not involve writing code). Then if people are mostly happy with them (esp. djwillia) we switch to the new interfaces *before* releaseing Mirage 3, but without actually implementing >1 net/disk.
<yomimono>
mato: so then attempting to use >1 net/disk would be a runtime failure until implemented?
<mato>
yomimono: ...which we can implement *after* the release, but without changing the interface types.
<mato>
yomimono: that's the general idea
<avsm>
isnt this a solo5-internal detail? it doesnt need any core revs to the types, does it?
<yomimono>
mato: gotcha.
<hannes>
mato: +1
<avsm>
or does it affect the config.ml definitions somehow?
<hannes>
avsm: the C interface in mirage-net-solo5 likely needs change
<djwillia>
mato: sounds like a good plan to me
<mato>
avsm: No, but it needs revs to all the C interfaces, which are currently split between mirage-solo5, mirage-net-solo5, etc etc
<avsm>
right, but it only affects the mirage-*-solo5 packages, and nothing else
<yomimono>
mato: but are expected to move as part of ongoing stub work, right? or am I conflating things?
<mato>
yomimono: that depends on how the ongoing stub work turns out, but in any case there will still be separate stubs for Solo5, Xen and UNIX
* yomimono
nods
<mato>
(at least for the "device driver" bits)
<avsm>
yeah, there will likely be different archives since each will be compiled separately
<yomimono>
basically I'm trying to figure out whether this has a dependency on anything else that we're still waiting on
<avsm>
ok, so my aim is to have a proposal/PR for the multi stub compilation in the next week, or a good excuse why its not working :)
<yomimono>
but it sounds logically separate from anything else that's ongoing
<mato>
yomimono: changing the Solo5 C interfaces? not really...
<mato>
yomimono: yes, separate
<yomimono>
mato: good, sounds like we're in agreement
<avsm>
great, also in agreement here
<reynir>
o/
* yomimono
high-fives reynir
<hannes>
avsm: could you elaborate? I thought nocrypto already has that multi-stub thingy...
<yomimono>
avsm: that's awesome btw
<mato>
yomimono: it's just a case of "let's do the churn now rather than later". Of couse I'm not promising we'll never need to change those C interfaces again, but we can at least have a crack at it.
<avsm>
hannes: not tried it yet; porting tcpip is the experiment to confirm that it works
<yomimono>
mato: sure. now's an excellent time to do that.
<avsm>
i have a topkg port of tcpip alongside
<avsm>
(that removes pack, uses module aliases, and all the goodness of the new stuff)
<avsm>
but its blocked on stub compilation
noddy has joined #mirage
<hannes>
stub compilation works (by awesome @pqwy) now even on FreeBSD ;) -- I tried and succeeded
<avsm>
woop, great stuff :-)
<mato>
ok. the last bit on solo5: There is now a "solo5-mkimage" tool, which can turn a virtio unikernel into a disk image, and it has out-of-the-box support for Google Compute Engine images.
* noddy
back
<mato>
so it's now super easy to run Solo5 on GCE
<djwillia>
mato: awesome!
<avsm>
yay!
<yomimono>
mato: this is rad!
<hannes>
mato: that's great! also solo5-virtio-run.sh :D
<mato>
anyone who wants to experiment i'd encourage you to sign up for the free trial $300 credit and go for it
<mato>
(I can post a TL;DR with instructions to the list...)
<avsm>
yes please
<yomimono>
mato: that'd be nice! I'm interested in moving my blog off AWS to GCE
<yomimono>
deploy cycle < 20 minutes would be extremely nice
<avsm>
in general, please dont assume that most people read the GitHub traffic as there is so much of it, so a brief update to the list on new stuff would be appreciated
<mato>
yeah, will do
<avsm>
anything else on solo5? sounds like its all full steam ahead! really excited to deploy it
<mato>
btw, met up with @sgrove over the weekend, he is running Mirage in production (both unix and solo5 on GCE)
<avsm>
awesome, that was one of his main complaints at his CUFP talk (difficulty deploying)
<mato>
done with solo5 from my side....
<djwillia>
all that is so great! mato, you're the man!
<avsm>
So docs.mirage.io is pretty fun -- I've been sending updates to the list, but the trove is looking increasingly complete
* mato
bows
<avsm>
It's also at the point where we can shift over to odoc (the new cross referencing backend) by default, and retire ocamldoc
<yomimono>
ok, let's move on to release stuff then :) avsm, we'll skip you ahead since you started us off on docs.mirage.io
<noddy>
* wait, q
<avsm>
yomimono: sorry, skipped ahead ;-)
<noddy>
avsm: which kind of multi-lib support are you working on now?
<avsm>
noddy: just a recipe for packages like tcpip to build separate sets of archives for installed backends
<noddy>
avsm: how is that different from ocb-stubblr, then?
<avsm>
so if mirage-solo5 is installed, it will also build an archive for that from the CFLAGS specified there
<avsm>
its probably not -- i've just not had a chance to rebase my port to use it
<noddy>
will you rather try it, or go ahead with publishing a separate system?
<avsm>
I've been waiting for yours to be published before continuing... the idea is to use ocb-stubblr so that we have one stub compilation system instead of a myriad of build rules
<noddy>
yeah, i'd like all that cruft in one place. asking, to see if something's missing or poorly supported
<noddy>
topkg 0.8.1 is about to rel any hour now
<avsm>
will let you know as I hack on it! thanks for getting ocb-stubblr out of the door :)
<noddy>
i rel stubblr in lockstep, the world is back on track
<noddy>
it also works for non-mirage. i got sick of ocamlbuild.
<avsm>
back to docs.mirage.io: it looks like we can retire ocamldoc unless there are some objections
<avsm>
the issue is that ocamldoc can never support ppx in mli interfaces, whereas odoc uses the compiled cmti and so works fine
<avsm>
e.g. if you look http://docs.mirage.io and scroll down, there are lots of errors (pcap-format, ...)
fructase` has quit [Remote host closed the connection]
<avsm>
but there are some layout issues. If you can start using the odoc URL as your day-to-day doc reference, please report layout issues on https://github.com/mirage/mirage/issues/609 so daniel, trefis and lpw25 can fix them
<avsm>
odoc still requires OPAM pins to build, but release is "soon" hopefully
<hannes>
I'm in favour of odoc. but also think that mli shouldn't depend on ppx rewriters
<avsm>
well it's part of the language spec, so we can choose to ban them but not control third party libraries
<noddy>
mli is just a source for cmti much as ml is a source for cmx
<yomimono>
afk for a few minutes, sorry
<hannes>
avsm: you mentioned some earlier time that there might be the chance to run ppx at release time, rather than at build time :)
<avsm>
yeah, jeremie is working on this and has made progress for the jane street releases
<avsm>
should see what he's done next week
<avsm>
there is a general desire to remove ppx from the "released" build chain
<avsm>
any other q on docs?
<avsm>
oh, I ran the "this week in opam" scripts for October and filtered out mirage libraries
<avsm>
that's me on docs unless anyone has any questions!
<hannes>
should the Dockerfile.doc contain all libraries, or is a reverse dep sufficient?
<avsm>
i'd prefer explicit roots, although it doesnt need it
<hannes>
(it is sufficent to find docs at docs.mirage.io, but unclear where else this list is used)
mort___ has joined #mirage
<avsm>
I'm going to start annotating tags in opam with information on library release status as well (stable, beta, etc), so it would be useful to have an enumerated set
<avsm>
hannes: first docs, but it is also the source of truth for cmt and build artefacts
<hannes>
release status?? based on what? manual reading through the code?
<avsm>
no just whatever the author wants
<avsm>
i.e. is this a stable library where semantic versioning is respected, or more a WIP set of releases
<avsm>
there's quite a varied set of release conventions in the list at present
<avsm>
quick poll: who has actually been using docs.mirage.io, vs (for example) merlin locally?
* avsm
uses docs.mirage.io since he admittedly has not got merlin setup
<hannes>
I'd be worried that this information gets out of date quickly... semantic versioning: we should agree to enforce it on mirage libraries IMHO (but only makes really sense if we agree in the entire OCaml/OPAM community)
<yomimono>
I have briefly but quickly reverted to grep :(
<noddy>
grep + merlin + more grep too
<hannes>
avsm: I used the odoc part of it to find some conduit interfaces, decided to drop using conduit, though
<mato>
grep + google + a bit of docs.mirage.io
<yomimono>
I think the value of hosted docs is in the hyperlinking
<yomimono>
that's the only time I used hosted docs for Irmin, for example, but it was invaluable then
<mato>
that and an integrated smart search would be cool
<yomimono>
so I think the cross-linking is huge
<avsm>
search intersects with Merlin quite a bit
<avsm>
but I get the "CLI preferred" feedback clearly
<GemmaG>
Whilst we are on the topic of Merlin… I've been asking different users/groups for feedback on Merlin for Fred to use
<hannes>
mato: search for names of values/types/modules? or type signatures?
<GemmaG>
More feedback of how/when you use it, and any problems you have/feature requests etc would be useful :)
<yomimono>
gemmag: how should folks get that feedback to you?
<avsm>
Hm, that would be useful GemmaG -- I primarily have issues with not setting it up as my OPAM switches are always out of date, so I'll give you newbie fail feedback :)
<GemmaG>
Gooood q - atm email would be great.
<GemmaG>
Working with Fred to collate it all into a workable roadmap :)
<mato>
hannes: names generally
<GemmaG>
avsm: newb feedback always welcome :p
<avsm>
Yay, glad Merlin is being given attention! I'm intending to switch to using it as soon as I sort out my OPAM2 setup
<djwillia>
btw is there a hard date in mind for the Mirage 3 release yet?
<avsm>
i would like it to use the odig cmt database though
<noddy>
i would like to push the shedding of some bikes on the agenda.
<noddy>
... and it's about the c stubs, again.
<yomimono>
djwillia: what a coincidence, we have an item on the agenda called "release schedule"
<yomimono>
...and since the c stubs (as they relate to coinstallability) are a blocker, maybe noddy should get priority
<djwillia>
i don't see amir here, but I've been working with him to get the right IBM people to be able to make a quote about the release
<djwillia>
it looks like we'll be able to have someone pretty high up say "MirageOS is cool"
<djwillia>
or something along those lines
<avsm>
yep, I've been in the loop on that as well. That's awesome!
<avsm>
noddy: we've got 12 minutes left. are you typing? :-)
<gemma_>
That's great!
<noddy>
aha, so. we seem to be commited to building multi-platform stubs. because stubs are part of the language, and supporting them is right and proper.
<noddy>
now there is some automation for _building_ them, but our api for _using_ that is a bit crufty
smondet has joined #mirage
* avsm
was hoping some ctypes magic glue would help fix that
<noddy>
it's a bit of a bikeshed as i'd like to move one way of stuffing extra info into META for `mirage` to use to another way of stuffing that info there for that to use
<noddy>
this is more general, gobs of libs don't use ctypes
<avsm>
the litmus test is: if we add a new (say openbsd/vmm) backend, does this require going back and changing any META files, or just altering the mirage tool?
<hannes>
this "native" confuses me tbh
<mort___>
so, "native_archive(xen) = nocrypto_stubs" ?
<avsm>
hannes: native is ocamlfind-speak for ocamlopt
<mort___>
or something else?
<noddy>
hannes: it's different from the ocalm system backing that mirage runtime; this is related to how to compile pure c code and the ocaml runtime it's related to
<noddy>
avsm: it requires changing *ALL* META files ever.
<avsm>
but why do we have to enumerate every backend in the META file?
<djwillia>
(sorry guys i have to run, but good to see you all and i'll be looking for the rest of the transcript later!)
djwillia has quit [Quit: Page closed]
<avsm>
djwillia: see you later!
<yomimono>
thanks for joining us djwillia :)
<noddy>
avsm: if we don't, we have a hard dep on an unproven convention. it's easier to commit to a naming convention for these libraries and just compute that in the tool.
<mato>
avsm: if that backend was done via solo5 then it'd not necessarily mean a new backend
<avsm>
why not native_mirage = nocrypto_mirage_stubs
<noddy>
IF people are cool with that.
<avsm>
well yeah, I guess META can be generated in the topkg world
<noddy>
in that world, you write META by hand
<avsm>
currently, but not forever
<noddy>
actually, should we just drop that and adopt a convetion for naming?
<hannes>
noddy: I struggle that you want to go through 10000 libaries and fix all the META
<avsm>
I prefer a convention for naming, enforced by the build rules
<noddy>
hannes: you can add dual-logic to the tool. plus, not that many mirage-ready libs out there.
<noddy>
avsm: then we get to drop META lines, but every package with c stubs that runs on mirage needs to have lib<package>+<target>.a
agarwal1975 has quit [Quit: agarwal1975]
<noddy>
that's totally doable, the logic can live completely in, say, stubblr. but it couples stuff.
<avsm>
yeah I prefer that model so we can ensure that the C code we are using is compiled correctly
<avsm>
I worry quite a bit that we link in incorrect ABIs that work by accident
<avsm>
we can relax the coupling at a future stage once this works for our existing C code (like tcpip checksums and so on)
<hannes>
noddy: I guess that's true... dual-logic is sth I'd avoid, but the number of mirage-ready C-dependent libs is pretty small, thus we can fix all of them easily
<avsm>
yes agreed hannes
<noddy>
so.... kill META lines, freeze a stub naming convention in the tool?
<avsm>
lets fix the 10 we have first, then move onto to the rest of the opam universe :)
<avsm>
yes, i think that would be a good start
<noddy>
no there's very few of these out there, really
<noddy>
a grep will unearth them
<avsm>
where the naming convention is parameterised by the backend being compiled for
<hannes>
dual-logic is the new backwards compatibility... a sign that people are too lazy to fix reverse dependencies...
<avsm>
yeah
<noddy>
avsm: libnocrypto_stubs+mirage-xen.a etc
<avsm>
ok, lets shift this to email. time's running out and there still gemma_'s agenda item
<yomimono>
+1
<yomimono>
noddy: can you mail mirageos-devel about this?
<avsm>
but thanks noddy -- i think this isnt bikeshedding and really important to get right
<noddy>
it's a long-term api being baked here.... :(
<hannes>
I added this release schedule item... can we briefly get an idea when people think a release will be there? this month? next?
<avsm>
which is fewer than most attendance at hack events :-)
<gemma_>
Now it's 14 😁
<avsm>
progress!
<avsm>
do prod people to fill it in, would be good to understand how we can improve things
<avsm>
I notice it's very difficult to get any useful feedback about docs.mirage.io as well -- i have to go around asking people individually to get anyone to respond
<gemma_>
Yes there's some great feedback so far, and more is certainly appreciated
<avsm>
(but when people answer its very useful!)
<yomimono>
hannes: I want to cut a beta as soon as we're done making major API changes
<yomimono>
hannes: but I just submitted PRs for a major API change this morning, and that's an attempt to get ready for major API changes I have yet to make re: errors
<hannes>
yomimono: I see you got some PRs just a few minutes before the meeting..
<yomimono>
hannes: yes indeed
<mato>
yomimono: random q, i saw in that PR that you touched some ipv6 bits, so do we actually have working ipv6?
<hannes>
uhh, and Canopy uses logs now \o/
<avsm>
high level release schedule: beta as soon as code settles, nov/dec to let beta settle and iterate on docs, nov/dec for self-hosting rollout, jan for stable release when its ready
<avsm>
mato: we have a full ipv6 stack, but no configuration :-)
<yomimono>
avsm: thanks, was just trying to type too much at once :)
<yomimono>
mato: (or automated tests for it afaik)
<mato>
avsm: ah. do we have at least a semi-working example? i can try and test it (have dual stack here)
<yomimono>
mato: there's a ping6 example in mirage-skeleton
<avsm>
mato: in mirage-skeleton, but no tcp yet i think
<yomimono>
that might get you started
<hannes>
avsm: the correct answer is: we have sth which (maybe?) interoperates with other IPv6 systems in unknown state. nojb was the only user (on unix afaik, no Xen)..
<yomimono>
mato: if you can tell me more about what you want for testing, I can try to get you something minimal
<avsm>
hannes: yeah, code quality is high, but we obviously need to deploy it
<hannes>
avsm: I'm not even sure which parts of IPv6 are there...
<mato>
yomimono: say a unikernel that does SLAAC (not DHCP) and serves something on TCP
<avsm>
i gotta run, AOB?
* noddy
afk \o_ \O/
<avsm>
otherwise poor engil is asleep, so I shall commit the meeting logs!
<avsm>
unpurecamelbot commit done
<unpurecamelbot>
done
<yomimono>
mato: afaik we have NDP but no SLAAC in the current implementation?
<yomimono>
mato: but TCP *should* work on top of it
<yomimono>
(danger: "should")
talex5 has quit [Quit: Leaving]
<yomimono>
mato: I'll try to find some time to hack on this later this week or maybe this weekend, if that works for you?
<yomimono>
(I want it myself for testing that changes I make to the STACK interface make it usable for both V4 and V6)
<mato>
yomimono: sure, no hurry
<mato>
yomimono: If we have NDP then we should have "most" of a naive SLAAC implementation
<yomimono>
that's probably the case -- there's stuff emitting log messages that reference it, but I'm not sure it's complete
<mato>
yomimono: it's basically "send out RS", "accept RA"
<yomimono>
mato: in that case I suspect there's enough, but I'll let you know how I get on
<reynir>
Hmm, maybe it would make sense to add a feedback form/email to docs.mirage.io ?
jermar has quit [Ping timeout: 244 seconds]
<hannes>
reynir: there's always https://github.com/mirage/mirage/issues/609 -- and I think docs is completely autogenerated (thus having a link to mirage issue tracker is hard)
<reynir>
Hm
<avsm>
reynir: i might just sed the output html ;-)
<avsm>
lambdasoup is a great ocaml library for this
<reynir>
fwiw I find docs.mirage.io useful, especially when you have to "chase" types :)
rgrinberg has quit [Remote host closed the connection]
thomasga has left #mirage [#mirage]
rgrinberg has joined #mirage
<yomimono>
thanks for the comments on dhcp/ipv4 prs, hannes :)
mort___ has quit [Quit: Leaving.]
<hannes>
yomimono: thank you for those patches! this is a great improvement!
<hannes>
yomimono: shouldn't the TCP/IP stack get a V1_LWT.ipv4_config an be happy? (and I'd expect charrua-client for now to emit a single element, rather than a stream..)... I think than we can get away without any mention of dhcp inside of TCP/IP stack \o/
<yomimono>
yes, I was just replying to you :)
<yomimono>
I initially did this with an ipv4_config argument but it's not obvious how to do that nicely with functoria
<yomimono>
hence the current design
<yomimono>
(because you then end up with an extra functor argument to Ipv4.Make representing the Dhcp object invoked to get the ipv4_config)
<yomimono>
I was thinking about how to fight this and then decided that it wasn't wrong
<hannes>
ic. well, I don't have a solution, maybe it is worth putting an issue onto mirage/mirage about it and solve it at some later point?
<yomimono>
but it's possible to remove the dhcp stuff from tcpip in the current design, and just move the dhcp_ipv4 module to charrua-client
<yomimono>
so if that's the goal it's quite achievable :)
<hannes>
it is a worthy goal imho
<avsm>
the main blocker to that originally was the need to maintain socket compatibility, but that's increasingly a non-issue
<avsm>
Dhcp clients do so many grungy things with rawlink...
<yomimono>
do you mean running the dhcp code on top of plain sockets?
<yomimono>
(the new design nicely sidesteps the issue by demanding a V1.NETWORK instead of V1.UDP for dhcp setup)
<yomimono>
(by "sidesteps" I guess I mean "refuses to address")
<avsm>
yeah, it is difficult to map dhcp clients onto POSIX sockets (without raw mode)
<avsm>
so the dhcp client was embedded deep in the tcp stack for expediency
<avsm>
but that's clearly the wrong place to put it
mcclurmc has quit [Ping timeout: 260 seconds]
gjaldon has joined #mirage
noddy has quit [Ping timeout: 260 seconds]
<gjaldon>
hi there! are pioneer projects still a thing?
<gjaldon>
I'm new to OCaml and Mirage but am keen on contributing by taking on some easy tasks. Saw the Pioneer Projects idea and was wondering if it's still ongoing
<hannes>
gjaldon: yes, sure. look what you're interested in, interact with us (mirageos-devel mailing list is a good place to start introducing you + your interests)
<gjaldon>
hannes: ok great! I'll introduce myself via the mirageos-devel mailing list :)
yomimono has quit [Ping timeout: 245 seconds]
rgrinberg has quit [Remote host closed the connection]
<avsm>
gjaldon: great!
rgrinberg has joined #mirage
grinbergr has joined #mirage
noddy has joined #mirage
mort___ has joined #mirage
avsm has quit [Quit: Page closed]
brson has quit [Ping timeout: 245 seconds]
fgimenez has quit [Ping timeout: 250 seconds]
fgimenez has joined #mirage
fgimenez has joined #mirage
fgimenez has quit [Changing host]
fgimenez has quit [Read error: Connection reset by peer]
jermar has joined #mirage
rgrinberg has quit [Quit: WeeChat 1.6]
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
mort___ has quit [Quit: Leaving.]
gemma_ has quit [Quit: Connection closed for inactivity]