qyliss changed the topic of #spectrum to: A compartmentalized operating system | https://spectrum-os.org/ | Logs: https://logs.spectrum-os.org/spectrum/
<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
<IdleBot_85f8451c> fn symlink(…) -> io::Result<Entry> { Err(io::Error::from_raw_os_error(libc::ENOSYS)) }
<IdleBot_85f8451c> So, CrosVM dislikes symlinks
lzmartin1 is now known as lzmartinico
maxdevjs has joined #spectrum
nicoo has quit [Ping timeout: 240 seconds]
nicoo has joined #spectrum
<qyliss> Reasonable IMO
<qyliss> Especially for their use case