<yomimono>
when you call netif.connect (), you get a new record each time even though each one will be passing data through to the same interface
<yomimono>
(if I understand correctly)
<yomimono>
it's not a huge deal until you start trying to, for example, register listeners at different levels of the stack
<Drup>
nobody should call netif.connect except the piece of code involved in the netif device
<Drup>
and that would be wrapped in a lazy, so evaluated only once
<Drup>
(unless, of course, you declare several different net interface)
<yomimono>
except that ipv4 calls ethifv4 calls netif.connect, and ethifv4 calls netif.connect...
<yomimono>
it's possible my question is poorly formed because I don't understand Lazy well
<Drup>
let me check the code
<Drup>
No, it's what I though, Netif.connect is only called in the net interface declaration
<yomimono>
but it's not just the repeated calls to connect that are a problem; if you have two different records representing, say, the ipv4 layer, and you configure one of them but use the second as an argument to a listen function, you'll get some unexpected behavior
<yomimono>
which is generated from mirage-skeleton example network
<Drup>
yeah
<yomimono>
there are a bunch of records that are generated in stackv4_dhcp1
<yomimono>
hang on, sorry, I'm thinking through this and (as always) it's possible that I'm wrong
<Drup>
It's okay, the invariants are a bit weird
<mort___>
(OT: re ganders, as an english-english speaker I would certainly understand the phrase "have a gander" and I wouldn't associate it as particularly american, fwiw)
lobo has joined #mirage
<yomimono>
the udp and tcp records are constructed with their own ip record, invisible to the caller. but the only ip record that the application will have access to is the ip record that's made in stackv4_dhcp and returned in the stack record
<yomimono>
so if the application then configures the ip, it won't be configuring the ip that the udp and tcp records have stored
<yomimono>
(if I'm reasoning about this correctly)
<Drup>
yomimono: hum, don't they all use the one returned by the ip device ?
<yomimono>
drup: IP records get told about their configuration (either by manual configuration or via DHCP), they don't autodiscover
<yomimono>
not sure what you mean by "returned by the ip device" though?
<Drup>
by "ipv411 () " in the code you pasted
<Drup>
I think the issue you are pointing out is the same as the fact that too call of this function don't return the same record
<Drup>
two calls*
<yomimono>
nope. connect optionally takes some configuration arguments but there's mutable state in the record that the user can change later
<yomimono>
IPv4.connect, that is
<yomimono>
Drup: yeah; it'd be fine if either each call returned the same record or we only made one call
<Drup>
yomimono: originally, the unit functions were there to delay side effects
<Drup>
I think I just naively assumed referential transparency and was ridiculously wrong about it.
<Drup>
(I don't remember if I added that in functoria or not)
<Drup>
so, instead of using unit functions to delay side effects, we could just use lazy, which would mean all the values are computed once.
<yomimono>
OK, sounds reasonable to me.
<Drup>
I will try that just after I finish writing my rebuttal :<
<yomimono>
can your rebuttal just be "THE REVIEWER IS A BUTT"?
<yomimono>
(ideally accompanied by a crude drawing of a butt)
<Drup>
I think it's not the best strategy if I want my paper to be accepted.
<yomimono>
That's no fun.
<hannes>
Drup: that's ESOP?
<Drup>
yeah
<hannes>
is there a generic last-recently-used data structure in some OCaml library? what I would like to have is a cache which does not grow beyond XX entries..
<hannes>
Drup: what about?
<Drup>
eliom
<Drup>
hannes: ask on #ocaml, I'm sure companion_cube has an idea /D
<Drup>
yomimono: tbh, I was very tempted to add at the end of the mail:
<yomimono>
works for the mirage-skeleton network example, but generates something uncompileable for the more complicated thing I was trying to do something else with
<Drup>
Oh ?
<yomimono>
I'll put that unikernel up somewhere, just a sec
<yomimono>
tracing-related
<Drup>
aarrg
<Drup>
I told thomas that it would break, it didn't miss =_=