Messages in this thread |  | | Date | Sun, 27 Aug 2000 21:02:30 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: SCO: "thread creation is about a thousand times faster than on |
| |
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/
|  |