Re: [PATCH 7/7] binfmt: Introduce the binfmt_img exec handler

[Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>]

On 07/23/2011 12:45 PM, Tejun Heo wrote:
> Hello, Pavel.
> 
> On Sat, Jul 23, 2011 at 12:17:48PM +0400, Pavel Emelyanov wrote:
>> The basic idea is very simple - you have to create a process with a defined
>> values in registers and defined set of memory mappings (with the memory
>> contents). This creation is obviously done by some (maybe another) process.
>>
>> Thus we have two ways to go - either we transform the restoring task into
>> the target one or we freeze the target one and repopulate it "remotely".
>>
>> The 1st approach seemed to be more elegant to me, and with this one we do
>> already have an API for turning one VM+regs into another - the execve.
>>
>> If you can suggest another way - I'm open for discussion.
> 
> Just restore it using the usual system calls - clone, mmap, open....

I can't clone/mmap/open registers (yet, unless we decide to have /proc/pid/regs
file, do we?). Neither can I do it for anonymous private mappings :(

> There is no reason for the kernel to do it and kernel can't even do it
> properly without going way outside of the existing exec(2) conventions
> unless you're planning to make exec(2) create multi-threaded process
> and I don't think that's a wise direction.
> 
> Thanks.
>