<qyliss>
I'm not that interested in the built-in 9p either, but it's useful enough for testing
andi- has quit [Remote host closed the connection]
andi- has joined #spectrum
cole-h has quit [Quit: Goodbye]
<IdleBot_85f8451c>
Well, I hoped that either built-in p9 or builtin virtio-fs could be used to mount the store!
maxdevjs has quit [Ping timeout: 246 seconds]
multi has quit [*.net *.split]
multi has joined #spectrum
AllaDelight has joined #spectrum
AllaDelight has quit [Client Quit]
<qyliss>
Cool, now I can dynamically add Wayland sockets at runtime
<qyliss>
That was surprisingly easy
<pie_>
:O
<IdleBot_85f8451c>
In what direction? You can have a Wayland VM that can get more incoming Wayland connections than initially planned?
<qyliss>
Well, more incoming sockets
<qyliss>
Which can be Wayland connections
<qyliss>
(And indeed that's why I wrote this)
<IdleBot_85f8451c>
And you can have honest incoming sockets in a VM?
<IdleBot_85f8451c>
Which I guess could have many incoming connections naturally…
<qyliss>
No
<IdleBot_85f8451c>
Which side requests the extra sockets? VM via some server?
<qyliss>
These are virtio_wl sockets, which generally have to be interacted with using the virtio_wl ioctls
<qyliss>
Although you can use read() and write() on them, like a pipe
<qyliss>
But no send/recv/sendmsg/recvmsg
<qyliss>
And you can't accept() on these
<qyliss>
My motivation for making it possible to add new sockets at runtime is to work around the lack of accept()
<qyliss>
Extra sockets are added my the host
<qyliss>
I envision it working like: when a new application VM is started, the host code that starts that crosvm creates a socket pair and connects one end to the Wayland VM, and the other to the application VM
<IdleBot_85f8451c>
Oh right, you can create two connected sockets that are both listening ones
<qyliss>
Yeah
<IdleBot_85f8451c>
And then you need to use a separate control socket to tell VM to actually connect to the new socket