On Sun, 27 Apr 2003, Davide Libenzi wrote:
> This is very much library stuff. I don't think that saving a couple of
> system calls will give you an edge, expecially when we're talking of
I guess it depends on what is considered saving. To be honest, my area of
interest is embedded systems. uClinux might benefit from such a syscall
(not that I have much experience with Linux on mmu-less hardware).
The idea would be to avoid the syscalls needed. I looked at the typical
fork-exec code I write and it does something similar to:
if (fork() == 0)
{
for(i = 3; i < NFILES; i++)
close(i);
sigaction(...);
sigaction(...);
exec();
}
The system call I was proposing would have a few benefits:
(1) Because of the file mapping array that can be provided, the
closing of the file descriptors isn't necessary (close-on-exec
isn't always convenient to use). Neither is the dup()ing of
file descriptors for things like pipelines.
(2) There is always the difficulty of finding out in the parent
if the exec() fails. Sure you can stat the path, sure you can send
a signal or do this countless other ways. But the single syscall
would make this a no-brainer.
(3) We would eliminate the page faults for the new stack as the child
runs to setup the environment. I guess this could save a a few free
pages for a millisecond. Yeah, minor... but if you have a large
system with 1000's of users it may matter.
Of course, a new system call is intrusive in the kernel. One option is to
prototype this as a library function first, see how much use it gets and
then decide later on to move it to the kernel.
L8r,
Mark G.
-
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 : Wed Apr 30 2003 - 22:00:28 EST