[uClinux-dev] Avahi AutoIp for No-MMU systems with ucLinux

[Muthuselvan Sivam]

Hi,

We're running ucLinux on a coldfire processor with no MMU.
And we're trying to run avahi to get autoip feature.

And currently I'm facing the below issue.

We're having a function call fork_dispatcher inside a function loop() in
the avahi-autoip main.c file, which will create a child process. This child
will create a pipe to read the IPv4LL address from the parent, which writes
the address, interface name etc, into this pipe. Since our child (created
by vfork) is currently running and waiting in fread (a blocking call), it
is not giving space to the parent to write the data, which the child
expects.

In No-MMU systems there is no fork, hence we have to use vfork, which will
block the parent untill child calls _exit.

And I also tried daemonizing the child and calling clone, instead of vfork,
but nothing works out.

Could anyone tell me whether there is any patch available for avahi autoip
for No-MMU systems in uclinux. I've googled but unable to find a patch.
Kindly help.

Thanks and Best Regards,
Muthuselvan S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20120829/dc47546d/attachment.html>

[Gavin Lambert]

Post by Muthuselvan Sivam
We're having a function call fork_dispatcher inside a function loop() in
the avahi-autoip main.c file, which will create a child process. This
child will create a pipe to read the IPv4LL address from the parent,
which writes the address, interface name etc, into this pipe. Since our
child (created by vfork) is currently running and waiting in fread (a
blocking call), it is not giving space to the parent to write the data,
which the child expects.
In No-MMU systems there is no fork, hence we have to use vfork, which
will block the parent untill child calls _exit.

To get "real" fork behaviour out of vfork (such that both parent and child
are running simultaneously), you must make the child process call one of the
exec functions (usually as soon as possible after the vfork).

Typically, you would re-exec the same binary with a special command-line
parameter telling it to perform the child task workload instead of normal
operation. Or to save a bit of memory (especially if the child task is
simple), execute a separate helper binary instead.

Note however that after the exec the child process will have its own clean
memory space, so you can't have it inherit state from the parent that way;
you'll either need to pass anything required via the command line or use IPC
mechanisms such as pipes or explicit shared-memory blocks.

[Michael Schnell]

Post by Gavin Lambert
To get "real" fork behaviour out of vfork (such that both parent and child
are running simultaneously), you must make the child process call one of the
exec functions (usually as soon as possible after the vfork).

"Real fork behavior" also includes creating threads (parent and child
share memory, open files and other stuff). But this is better achieved
using Posix Threads provided by ptheradlib. I suppose pthreadlib is
available for nearly all archs.

-Michael

[Gavin Lambert]

Post by Michael Schnell
"Real fork behavior" also includes creating threads (parent and child
share memory, open files and other stuff). But this is better achieved
using Posix Threads provided by ptheradlib. I suppose pthreadlib is
available for nearly all archs.

No. I think you're thinking of clone(), which allows you to specify that
the cloned process completely shares all memory, instead of being duplicate
but separate (usually copy-on-write) as fork() does.

Threads imply shared memory, not duplicated memory; so you could implement
threads via clone() but not via fork(). (And not via vfork(), since even
though that has shared memory it doesn't have simultaneous execution.)

But as you said, if you want threads then you should use a threading library
instead.

[Michael Schnell]

Of course you are right, but as here it has been recommended to do
"exec()" with the same binary, this suggests that something like threads
is what is intended.

If the arch does not provide for reusing code-page memory (via MMU, XIP,
and/or fully relative addressing), loading the binary a second time
might be inappropriate due to loading time and memory hogging. Thus
using threads might be a better idea.

-Michael