CRIU and Weston

[Pekka Paalanen]

On Fri, 30 Jan 2015 21:31:24 +0200
Ruslan Kuprieiev <kupruser at gmail.com> wrote:

> Hi!
> 
> I would like to add checkpoint/restore support of a graphical app(no
> gl) that uses wayland.
> I'll appreciate any thoughts and ideas on how to accomplish that as
> well as what simplest
> app should I start with.
> 
> After discussing it on #wayland, it looks like I should start with 
> creating patches for weston
> to implement needed getters and setters to obtain client's state on
> dump and set it on restore.
> 
> I was wondering if you could help me by providing some info about
> amount of data, that
> describes the client's state.
> 
> I'll also appreciate any hints on where to start digging into weston.

Structs weston_surface, weston_view, weston_subsurface,
shell_surface... everything contained by those is a candidate, plus
everything that ever references those or those reference. Shared
mmapped files, file descriptors...

I have very hard time seeing what could work for you while not
rewriting the world.

Maybe you could start by looking at software pixel buffers. A client
creates a file on tmpfs, mmaps and writes pixels into it, sends the file
descriptor to the compositor, and the compositor mmaps that file. So for
save/restore, you need to somehow reinstate this mapping in both the
client and the compositor. This is the fundamental, basic mechanism
how clients send content to the compositor, and the compositor
decides how long it needs it. Can you do that?

Clients send the file descriptor only once per wl_shm_pool. After that
they assume they can re-use the wl_buffers indefinitely. We have no
mechanism to revoke any.

Can you save and restore unix socket connections? Note, that
(re)connecting means starting from a clean slate in Wayland protocol
state wise.


Thanks,
pq