[CRIU] custom initialization during restore
Cyrill Gorcunov
gorcunov at gmail.com
Wed Aug 12 14:13:55 PDT 2015
On Wed, Aug 12, 2015 at 05:37:37PM +0300, Pavel Emelyanov wrote:
> >
> > This, actually brings a number of problems: the CRIU's pie code
> > (if I understand correctly we need to call some pre-sigreturn helper
> > functions, which are "external" in terms of CRIU symbols) is very
> > special one -- the main requirement is that all symbols must be
> > resolved, so in general we carry all the data needed for restorer
> > inside the memory blob which we're generating dynamically.
>
> Sure, but symbols resolution can be done before calling pie code. I
> would even add -- we can do it dump-time and save hooks' addresses
> into images :D
I see but for me this should be done like this
- criu reads plugin(s) and move them into restorer blob
- restore maps and etc
- before sigreturn criu pass execution into the plugin
- plugin does something (mmap/syscalls/openfiles or whatever)
- calls return
- criu calls sigreturn dropping all memory (including restorer
blob itself together with plugin) and all this goes transparently
to the dumped application
I must admit this actually not much different from what you
propose except I think this would limit the naming scheme. Currently
CRIU plugins doesn't care how functions are named.
So I won't argue if someone implement your idea ;)
> > we're applying strict rules on plugins structure and we assume
> > that such plugin does _not_ carry any unresolved symbols. Hm?
>
> The plugins we're talking about should better be per-application.
> Thus linking them into a process sounds more promising.
I'm not that sure because native criu plugins would look more
natural for me, but it's just an opinion, I don't have strong
preference yet.
More information about the CRIU
mailing list