[ale] compiled system calls versus shell scripts

[Danny Cox]

Christopher,

On Wed, 2003-10-22 at 16:12, Christopher Bergeron wrote:
> But what I'm wondering is if I create a simple C program 
> that just does:
> void main() {
>   system("modprobe whatever &");
>   system("ifconfig eth0 192.168.0.4 &");
> }
> 
> Would this give me a faster boot during this phase?  I'm thinking about 
> doing this and replacing my /sbin/init altogether.

	I doubt it.  System does it's thing by spawning a shell: it sez, "sh -c
'<system_arg_string>'", and lets the shell do the hard stuff.

	I'd continue to let the shell do it's thing.  After all, that's what
shells do best: fork and exec proggies.

	OTOH, if you want to experiment a bit, you might try the following,
Just To See.  The idea is to fork twice: the child forks again, but then
exits.  The "grandchild" performs the exec.  Since the "child" exited,
init now has the responsibility of reaping the child.  Something like
this:

	main()
	{
		pid = fork ();
		if (!pid) {	/* child */
			pid = fork ();
			if (!pid) {	/* grandchild */
				execve (filename, cmdargv, cmdenv);
			}
			exit (0);
		}
		/* NEXT! */
	}

	Of course, you must go to the trouble of setting up the cmdargv, and
cmdenv arrays, plus give the full pathname in filename.  You might check
out the exec* variants (execl, execv, etc.) in the C library to make it
easier, but it'll be slower, too.

	All in all, I'd bet the shell script would be just as fast, most likely
because the fork/exec will eat up most of the time compared against
everything else.

-- 
kernel, n.: A part of an operating system that preserves the
medieval traditions of sorcery and black art.

Danny