-
Notifications
You must be signed in to change notification settings - Fork 238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Duplicated network setup for stacks #476
Comments
Alternatively, instead of a unit function, we return a Lazy, this should solve the problem once and for all. |
Would you not still have the problem of distinct records (rather than everything being built on top of the same netif/ethif/ip/arp/etc record) with the lazy approach? |
I don't think so. The udp example would look like that : let udp1 = lazy (
let __ipv411 = Lazy.force ipv411 in
__ipv411 >>= function
| `Error _e -> fail (Failure "ipv411")
| `Ok _ipv411 ->
Udp1.connect _ipv411) |
This appears to have been fixed by mirage/functoria#44. @yomimono, can you confirm? |
Yes, all appears to be well now; closing. |
For unikernels that request a stack (like the network example in mirage-skeleton), Mirage currently generates a
main.ml
that duplicates connection code many times over and results in a stack built with distinct (but identically configured) records for the underlying implementations. For example, here's the snippet that generates thetcp
andudp
records, from amain.ml
made withmirage configure --xen
in the aforementioned example:Each calls
ipv411 ()
, which results in a newip
record.ipv411 ()
itself generates new underlying records each time it's called, resulting in output like the following when the unikernel starts up:Functions like
tcp1
andudp1
should probably take the required subcomponents as arguments, rather than generating them within the function and not exposing them.The text was updated successfully, but these errors were encountered: