On Sun, 27 Aug 2000, Alexander Viro wrote:
>
> Linus, there is no need in new mask for execve().
What you're saying is "there are other ways to accomplish this". And I
kind of agree. I still think the dynamic mask is the preferable option.
> We have two actions:
> 1. create a VM set up according to the contents of binary
Sure. Another ELF marker, whatever. It would work, and probably cover the
needs. Especially as "the needs" aren't that big, as this has actually
never come up except as a theoretical discussion ;).
However, I just don't like it. We could do a lot of binary flags, but in
the end we should avoid doing it unless it is _really_ really needed. I
don't think it is. I'd much rather have a plain executable format, and
dynamic ways of making that executable do things differently.
> 2. create a private copies of some previosuly shared components
> Notice that there is no need to combine them in one - if you want
> exec-with-private-files you can make your files private and then call
> execve(). And you may very well want to get the private copies of
> files/signal handlers/etc. without doing exec(). We even have a natural
> API for that.
Now THIS I agree with. Good notion - I like "unshare(CLONE_xxx)" as a
system call. I just wouldn't overload it with "clone()" (ie I'd make it a
new system call), because I'm just too attached to the fact that "clone()"
applies the bitmask on the _new_ thread and leaves the old thread
untouched. Changing the current thread is a fundamentally different
things, I think. And is worth a special system call.
That would indeed make my execve() flag totally unnecessary - and allows
for unsharing even without the execve().
Color me convinced.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:20 EST