[uClibc] vfork patch for noMMU arches.

Dylan Griffiths Dylan_Griffiths at pmc-sierra.com
Wed Jun 1 15:26:52 UTC 2005

Marc Leeman wrote:
> If I read your patch correctly; by replacing the fork() calls in
> toolchain_build_nios2/uClibc/libc/unistd/daemon.c of uclibc with vfork(),
> applications that depend (applets) on daemon (telnetd, httpd) could be
> compiled and run on archs without MMU?
> nice, I need to try this on nios ii

Yes and no.  vfork and fork do not have the same semantics (which is why
I don't like seeing vfork implemented as return fork()).  vfork
guarantees that your parent will run AFTER your child has either called
execve or _exit (not the libc exit, though).  fork, OTOH, guarantees no
order of execution, and does not share the memory space between the two
apps.  vfork is really a way to make an application into 2 threads, with
the new thread assigned a process id and then replaced with an
independant program.  For things like ash, that's fine and dandy because
that's how you'd run a program from a shell, but it's not going to allow
a transparent daemon implementation.

On the plus side, we can make a better daemon implementation.  Since
clone is a superset of fork and vfork, we can wrap it to provide
services like fork, vfork, and daemon.  I do have a daemon patch I'm
testing here for noMMU, I just want to make sure there aren't any side
effects of it.  The traditional daemon call is rather silly, because the
function uses a few syscalls to "fake" getting a parented to init, no
tty, no regain tty process.  You could add a flag to the clone call that
would tell the kernel to do these process entry changes itself and
simplify the daemon call a great deal (leaving the libc implementation
to only worry about the userland code, not the kernel state, as it
should be IMO).

My current version doesn't have a patch to the kernel, but I will
implement it if the version I have in testing doesn't work in the
userland I'm running here (Busybox, uclibc, etc).

More information about the uClibc mailing list