<IdleBot_85f8451c>
emily: POSIX has benefits in terms of enforcement of negotiations between upstream vendors. Later versions of SUS seem to slowly lose that enforced-negotiation benefits, though
<IdleBot_85f8451c>
Single API actually coming from negotiations of nsjail, firejail, AppImage, Flatpak, CrosVM upstreams could be interesting; but it does not look like we can get this…
<qyliss>
IdleBot_85f8451c: think you meant ehmry
<IdleBot_85f8451c>
Oops, yes, sorry
cole-h has quit [Quit: Goodbye]
<qyliss>
Hmm, problem
<qyliss>
crosvm seems to drop control messages sent to it before it's fully started up, but after its socket is created
andi- has quit [Ping timeout: 260 seconds]
<qyliss>
I'd really like it if I could if could tell it to use an existing fd as its socket. That would avoid any sort of waiting for it to make its own.
<qyliss>
But for now I guess I just need to see if I can figure out why these messages are being dropped rather than handled.
<qyliss>
Hmm, looks like I might have introduced this
<qyliss>
That's a good sign at least because I'll understand whatever code is responsible
<qyliss>
Wait, never mind
<qyliss>
wrong test case
andi- has joined #spectrum
<qyliss>
Okay I think I've figured it out
<qyliss>
This is a great bug
<qyliss>
I send a command, and it gets received by the main crosvm event loop. It's then forwarded to the relevant virtual device, and the event loop waits for a response (which is usually expected to come pretty much immediately).
<qyliss>
But! The device might not be running yet. Devices are activated when the driver in the guest sets the appropriate PCI bits. But with the event loop stuck waiting for a response from the device, it'll never notice that PCI write and activate the guest.
<qyliss>
So it'll just sit there forever waiting for a response that never comes.
<qyliss>
This is going to be a pretty invasive fix :(
leah2 has quit [Ping timeout: 260 seconds]
leah2 has joined #spectrum
cole-h has joined #spectrum
MichaelRaskin has joined #spectrum
amanjeev- is now known as amanjeev
jb55 has quit [Remote host closed the connection]
jb55 has joined #spectrum
<pie_>
tfw you arent writing erlang
<MichaelRaskin>
pie_: tfw when trying to build Erlang look-alike out of smoke and mirrors?
<pie_>
tfw i have no idea what im taking about
<pie_>
MichaelRaskin: ok i dont get it
<MichaelRaskin>
Well, on multiple levels you want to make parts isolated and at the same time make them keep track of whether the other side has disappeared…
<pie_>
that actually sounds pretty easy? just ping the remote? if it replies, the other side was there at some point in the past :p
<pie_>
so i guess what yo could do is replly with a message counter or whatever, something keeping track of what has been received, and then you know at least someof your messages have arrived
<pie_>
MichaelRaskin: idk how familiar you area with erlang, i just started. stuff is isolated by default and you can only communicate with message passing
<pie_>
for some meaning of isolated
<MichaelRaskin>
I never really wrote anything beyond toy examples
<MichaelRaskin>
But did read about the basics
<pie_>
but iiuc alyssas problem was that the event loop ended up stuck blocked somehow?
<MichaelRaskin>
I interpret the explanation as pointing to the core issue of passing the responsibility for something without making sure the target for passing is there