[CRIU] [PATCH 0/2] crit core-dump feature, v2

[Ruslan Kuprieiev]

On 30.04.15 20:52, Pavel Emelyanov wrote:
> On 04/30/2015 03:50 PM, Ruslan Kuprieiev wrote:
>>
>> On 30.04.15 15:39, Pavel Emelyanov wrote:
>>> On 04/30/2015 03:26 PM, Andrew Vagin wrote:
>>>> On Thu, Apr 30, 2015 at 10:40:11AM +0300, Ruslan Kuprieiev wrote:
>>>>> Do you mean make whole crit to be a standalone project?
>>>> After the discussion with Ruslan, we are both agreed that crit and all
>>>> related things should be in a separate repo.
>>> O_O  No, thanks. CRIT should be in CRIU for several reasons.
>>>
>>> 1. We have no criu show soon and w/o viewing the images life would be bad
>>> 2. Crit is supposed to be used for images conversion when we update the
>>>      images significantly
>>> 3. We have sophisticated pagemap+pages images, they can be stacked, and
>>>      we have to have a nice library to access those (even for python)
>> What do you mean by 3.?
> I mean that in order to get memory contents of a task user would need
> to do non-trivial simultaneous parsing of at least 2 images and more
> in case of stacked image sets. It would be nice if libcriu (or libcriuimg,
> I don't know) provided sane API for this and had bindings to other
> languages, e.g. python.
>
> IOW -- we should take page_read.c and API-ize it :)

But is there request for C api to read pages?
And btw, page_read.c doesn't contain everything one needs to read process
memory, as mapped files vmas are handled separately.
Process memory pages in criu is very complicated and not obvious at all,
but in core_dump I'm able to read any memory page I need using two
very simple and well-commented functions.

>> The only thing I want is keeping core-dump with it's family -- crit and
>> pycriu,
>> so I think this patchset should be accepted.
> I love the patchset :) I just doubt that the convert-to-core is the
> feature for crit itself.

But CRIT stands for _CRiu Image Tool_. Core dump converts _CRIU Images_ and
is, in fact, a _Tool_. So why should it _not_ be a part of crit?

>> Discussion about whether or not to move crit and pycriu in a separate
>> project
>> is secondary and I'm okay with both, although I think that moving might be
>> nice.
> No, crit and pycriu should remain in criu for the reasons described above.
>
> I'm looking at it this way -- if two components have dependency on each
> other (!), then it makes perfect sense to keep them together.
>
> In case of criu and crit they do -- criu (will) needs crit for images
> conversions, and needs (indirectly, via us) to see what's there in the
> images, crit needs criu to know the images format and structure. Contrary
> to this, crit-coredump needs criu (for images), but criu doesn't need
> coredump.
> -- Pavel