qyliss changed the topic of #spectrum to: A compartmentalized operating system | https://spectrum-os.org/ | Logs: https://logs.spectrum-os.org/spectrum/
dgreid_ has quit [Ping timeout: 240 seconds]
dgreid_ has joined #spectrum
cole-h has quit [Ping timeout: 264 seconds]
cole-h has joined #spectrum
<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