<qyliss>
Occurs to me we're going to need a pipe server as well as the memfd server
<qyliss>
But that should be simple enough to add. The hard part with the memfd server was figuring out how to structure it and where to put it.
<samueldr>
I'd put it in memory
<samueldr>
(sorry)
<qyliss>
:D
<qyliss>
Actually, maybe not, because AFAICT pipes in Wayland are usually created by the client
<qyliss>
At least, AFAICT that's how clipboard and drag/drop works
<qyliss>
Not sure if pipes are used for anything else
<qyliss>
But anyway, if they're created by the client that means Sommelier handles virtio_wl for them.
maxdevjs has quit [Ping timeout: 265 seconds]
cole-h has quit [Quit: Goodbye]
<qyliss>
puck: what do you think my chances are of being able to modify libwayland-server to use a virtio_wl display socket?
<qyliss>
wondering if I can avoid virtwl_guest_proxy
<puck>
the biggest issue would be the actual file descriptor proxying i think, and things like memfds coming from the wayland stuff too
<qyliss>
File descriptor proxying should be fine
<puck>
i suspect hooking up a replacement for wl_connection_read and wl_connection_flush shouldn't be too difficult. tho wouldn't you have to modify the clients too, or are those going to talk through a proxy still
<qyliss>
Clients will go through Sommelier
<puck>
right, if one end has the proxy than FD proxying shouldn't be the issue
<qyliss>
And memfds are allocated on the host using a server I wrote for that
<qyliss>
Actually, hmm. Can you accept() on a virtio_wl socket...
<qyliss>
I'm inclined to say no
<puck>
prolly not
<qyliss>
That could be a problem
<puck>
oh?
<qyliss>
The compositor accepts on the display socket
<puck>
right
<puck>
but that's handled by the wayland-server protocol too
<puck>
api*
<qyliss>
Not sure I follow
<qyliss>
Like, I'll need to modify wayland-server I think
<qyliss>
And I don't know what I'd to to replace that accept()
<puck>
right, sec
<qyliss>
puck: socket_data() in wayland-server.c if that helps
<puck>
wait, does the server end up running against virtio-wl too?
<qyliss>
That's the intention
<qyliss>
Want to have the server in a VM
<puck>
right, there's no real API for that yet i suspect.
<qyliss>
I suppose I could emulate accept
<puck>
i don't think you can *receive* sockets the same way they can be created in virtio_wl
<qyliss>
Have the main socket just send the name of another virtio_wl socket, and then you connect to that socket to get the client connection.
<puck>
oh yeah
<qyliss>
You can receive sockets, but they're reduced to basically just bidirectional pipes
<qyliss>
So no fds, etc.
<puck>
yeah
<qyliss>
But since you can have multiple virtio_wl sockets, I can probably abuse that
<qyliss>
Currently the list of those is static -- I'd have to come up with a way to add sockets to it a runtime
<puck>
i think you can probably add "receive 'proper' virtio-wl socket" to the api but hrmm
<puck>
seeing as you can have named contexts
<qyliss>
Yeah, named contexts are what I plan to abuse
<qyliss>
Probably easier to do that in userspace though
<puck>
yeah
<qyliss>
Hmm, this is gonna be complicated
<qyliss>
But should be possible
<qyliss>
Thanks
<qyliss>
Actually, this has a somewhat nice property
<qyliss>
It removes any accept() anywhere in the chain -- sorta cancels two of them out
<qyliss>
When an application VM is starting, create a socket pair. Connect one end to the application VM, and the other to the compositor VM.
<qyliss>
No accept() at all
<qyliss>
That's simpler than what I had before
<qyliss>
My only worry now is that the libwayland-server changes might be a bit invasive
<qyliss>
But I can still always fall back to virtwl_guest_proxy if so
<qyliss>
So, next step, then, is to make it possible to add a named virtio_wl context to crosvm at runtime
<qyliss>
That probably shouldn't be too hard
<qyliss>
I pretty much want to copy how changing usb devices on the fly works, probably.
<IdleBot_85f8451c>
Interesting. It looks like with CrosVM shared-dir I can ls files but not symlinks
amanjeev has quit [Quit: Logging off! Bbye!]
cole-h has joined #spectrum
<IdleBot_85f8451c>
I wonder if it is because of statx with no-follow-symlinks flag…
<IdleBot_85f8451c>
OOps, without…
<IdleBot_85f8451c>
OK… // symlinks are not allowed
<IdleBot_85f8451c>
Somehow I feel my interest in using built-in p9 support going away again