avsm changed the topic of #mirage to: mirage 2 released! party on!
nullcat has joined #mirage
nullcat has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
srenatus[m] has quit [Remote host closed the connection]
brson has quit [Quit: leaving]
srenatus[m] has joined #mirage
jermar has joined #mirage
boadie has joined #mirage
boadie has quit []
copy` has quit [Quit: Connection closed for inactivity]
mort___ has joined #mirage
agarwal1975 has quit [Quit: agarwal1975]
yomimono has joined #mirage
mort___ has quit [Quit: Leaving.]
tizoc has joined #mirage
seangrove has joined #mirage
tizoc has left #mirage [#mirage]
yomimono has quit [Ping timeout: 252 seconds]
yomimono has joined #mirage
agarwal1975 has joined #mirage
seangrov` has joined #mirage
seangrove has quit [Read error: Connection reset by peer]
seangrov` has quit [Remote host closed the connection]
rgrinberg has joined #mirage
brson has joined #mirage
ijc_ has quit [Ping timeout: 265 seconds]
ijc has joined #mirage
copy` has joined #mirage
mort___ has joined #mirage
mort___ has left #mirage [#mirage]
rgrinberg has quit [Ping timeout: 244 seconds]
<rixed> Is it intended that the tcpip stack doesn't implement a loopback and instead emmit an ARP requests when trying to connect to itself?
<yomimono> we had some discussion on this that landed on "it's weird to do this in the context of a unikernel, and would take some work to support, so we won't do it for now"
<yomimono> if you have a use case that needs some different behavior, we could think about it some more though
rgrinberg has joined #mirage
<rixed> yomimono: It's painfull to implement this at the application layer because it's hard to inject the bouncing frame into the receiving callback that's already blocked in a read. :-/ I guess that's a similar issue that you faced from within the kernel
<rixed> yomimono: I don't really buy the unikernel exemption argument though. You may have independant services running in the same unikernel and sometime one might want to communicate with another exactly as in Unix.
<rixed> yomimono: indeed that's my situation. So now I'm going to implement a net device and a routing stage above the kernel, which looks a bit weird
<rixed> Hopefuly that's temporary only, will reopen that bug and see :)
<rixed> BTW, my use case is a monitoring service that monitors itself, and a registration service that register itself... So I've hit this limit twice already :)
<yomimono> rixed: any interest in bringing this up on mirageos-devel?
<yomimono> oh nm, I see you commented on the issue
<rixed> yomimono: That's what I did a few days ago but the ML does not work for me (can receive the messages but cannot post aparently)
<rixed> yomimono: (that, or I'm greylisted for a looong time)
<yomimono> rixed: ouch :( I'm asking around to see who the ML admin is these days; I have a few guesses but I know it's not me
<yomimono> I know it's moderated but not sure who's doing the scutwork
<rixed> yomimono: Then my message will appear in the ML eventualy. Meanwhile I'm going to hack a workaround. It's the first behavioral difference I can spot with the unix version of my pet project
seangrove has joined #mirage
seangrove has quit [Ping timeout: 244 seconds]
tg has quit [Excess Flood]
tg has joined #mirage
mort___ has joined #mirage
rgrinberg has quit [Ping timeout: 250 seconds]
tg has quit [Excess Flood]
tg has joined #mirage
rgrinberg has joined #mirage
mort___ has quit [Quit: Leaving.]
yomimono has quit [Ping timeout: 264 seconds]
agarwal1975 has quit [Quit: agarwal1975]
Meeh has quit [Quit: No Ping reply in 180 seconds.]
Meeh has joined #mirage
Meeh has quit [Ping timeout: 244 seconds]
Meeh has joined #mirage
jermar has quit [Remote host closed the connection]