Hello, On Thu, Sep 01, 2011 at 04:13:54PM +0400, Pavel Emelyanov wrote: > Because with the handler restore process looks very natural and simple - each > task does the following steps > > 1. restore task resources (open files, set IDs, restore connections, wire back timers, etc.) > 2. call execve() to jump into new memory+registers context which is > a. unmap all the user memory > b. map required mappings > c. populate them with data > d. restore registers > e. restore IP But what about multiple threads? exec is already scary enough as it is and I don't think it would be wise to overload it for this. I don't really think binfmt handler would be able to achieve completeness without ending up with full de-serializer in kernel. There are a lot of states which already have API to manipulate from the userland thread itself and they all will need to be replicated in the binfmt handler. It really has to be full de-serializer if it wants to function like you described. And if we're gonna have interventions anyway, I can't see much point in implementing something which seems simpler - it's not gonna be actually simpler. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
