[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