On Tue, 13 Aug 2002, Ingo Molnar wrote:
>
> one solution would be a new syscall to set 'VM exit notification' address
> and value in the released VM. But since it would always come in pair with
> sys_exit() or sys_execve()
Why do you say that?
In fact, by looking at the current implementation of mm_release(), you
should realize that this is wrong.
We already have an interface where the parent wants to know about the
child doing a mm_release() - it's called vfork(). And the mm_release()
intention notification is done at _vfork_ time, not at exit or execve()
time.
This is my whole argument. It makes sense to say at clone time that "I
want to be notified when my thread exits" or "I want to be notified when
my thread no longer uses my address space". That makes 100% sense, and is
in fact something we're already doing with the signal mask, and with the
existing CLONE_VFORK case.
In contrast, it does _not_ make sense to say "I'm the child, and I'm now
exiting, so I want to notify my parent", because the child does not always
even _know_ when it is exiting.
For example, if you want to use the existing execvp() etc libc helper
routines, the final execve() is not going to be a magic system call. So
you cannot have a special execve_release() system call, because that makes
no sense within the libc.
I repeat: it is the _parent_ that knows whether it wants to be notified at
exit. Not the child.
Ergo, the "notify me on exit" should be a parent decision, and it might be
as simple as writing zero to the (same) "pid_t *" that it passed for the
pid information thing for startup.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 15 2002 - 22:00:33 EST