CRIU and Weston

[Ruslan Kuprieiev]

Hi Pekka,

Thank you for your response.

On 02/06/2015 03:05 PM, Pekka Paalanen wrote:
> 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?

Yes, CRIU is able to c/r mmap-ed regions of a client.
Could we just pass fd to the compositor when restoring a client?
I mean, like tell weston that that buffer is what we're starting from?

> 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.

Do you mean, that this is initial procedure?

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

In general - we can't, unless client and server are both in the process tree
that we're dumping.
But, maybe we could implement proper reconnecting to server socket, 
doing all needed
negotiations with server, and then passing saved fd of that pixel buffer 
you mentioned
before.

Btw, what simplest program you would suggest to start with? Maybe 
something that
simply draws some static picture?

>
> Thanks,
> pq

Thanks,
Ruslan