Re: Feature request: exec self for NOMMU.
From: Rob Landley
Date: Tue Dec 26 2006 - 19:45:46 EST
On Tuesday 26 December 2006 6:55 pm, David Lang wrote:
> > Worse, it's not always possible. If chroot() has happened since the
> > started, there may not _be_ a path to my current executable available from
> > this process's current or root directories.
> does this even make sense (as a general purpose function)? if the executable
> isn't available in your path it's likly that any config files it needs are
> not available either.
For a statically linked busybox it makes sense, but you're right that a
dynamically linked one is going to suck however you do it...
I guess what I really want to do is promote a vfork() to a real fork() after
the fact. Which sounds painful.
For the daemonize() case I want to unblock the parent and have it exit. Too
bad I can't call clone() with some kind of CLONE_VFORK_BACKWARDS so it blocks
the child until the parent exits. (Hmmm... CLONE_STOPPED doesn't help, just
moves the race...)
For the "new process runs code out of this executable" case what I really want
is an actual fork, hideously expensive as that is on nommu systems. (There
are things I can do to minimize that.) Maybe I can call clone() directly on
a nommu system to get it to fork, even when the C library hasn't got it?
> for something like busybox/toolbox where you have different functions based
> on the name used to execute the program, which name would you use?
The one from argv. (Notice how exec has a "path to executable" and then an
argv array? Nobody said that the path to executable and argv had to point
to the same string...)
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/