busybox 1.1.3 - fork on nommu

[Rick Garcia]

Rob Landley wrote:
> On Wednesday 25 October 2006 9:03 pm, Denis Vlasenko wrote:
>> Someone was lazy and didn't code the check.
>> Send patch to fix it.
>>
>> Well, I am unfortunately do not have nommu system here
>> (I would love an qemu-usable image of one. hint).
> 
> I never got one to run under qemu, but the uClinux guys did walk me through 
> setting up ARMulator:
> http://busybox.net/lists/busybox/2006-July/023392.html 
> 
>> I see that we have some NOMMU friendly helpers:
>>
>> * vfork_daemon_rexec() - a daemon() equivalent for NOMMU?
> 
> I kept meaning to replace that, never got around to it.  This is one of the 
> things a global argc/argv allows you to do, jump through fewer hoops 
> supplying it again when doing daemonize.
> 
> The problem is that vfork() blocks the parent until the child calls exec() or 
> _exit().  Even though all the parent wants to do is exit(), it can't unblock 
> to do so until the child execs something.  So we have to pull some variant of 

Isn't this just one of the inherent limitations of running without an 
mmu?  At some point, it's kinda necessary to accept that a nommu system 
is, in fact, a NO-mmu system.  There are some things it's just NOT going 
to be able to do.

> 
> It's possible that most of what it's doing with the fork thing can also be 
> done with things like setsid(), I'll have to check.  The one thing you can't 
> do without a fork is move your parent process: only our parent exiting will 
> reliably give us init as our parent process.  But if our parent process 
> doesn't reap zombies, how much do we really care?
> 
> Note you can also do pretty much all of daemonize() through a command shell, 
> ala:
> 
> (command > /dev/null 2> /dev/null </dev/null &)&
> 
> And yes, that backgrounds it twice intentionally...
> 
>> * spawn() - vfork()+exec()
> 
> I wrote that to be nommu friendly, yes.  Haven't stringently tested it.
> 
>> but none is applicable to the piece of code you are talking of.
>>
>> The more I look into it, init.c will need some surgery if you
>> want to make it work without forking (not fork+exec, just fork).
> 
> It was on my todo list. :)

Would it be worth it for me to go about making (or, more accurately, 
ATTEMPTING to make) 1.1.3 more nommu friendly, or should I jump ahead to 
1.2.2?  I'm going to be working this issue anyway...

It seems like it should be generally understood under busybox that fork 
isn't going to be reliable, and should be used cautiously... I mean, I 
don't expect every developer out there to bow down before the 
requirements of a system without a memory manager, but it would make 
busybox a much more flexible and attractive package if it addressed the 
issue directly.

> 
> Rob