[lkml]   [2006]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RFC: implement daemon() in the kernel
On Nov 20, 2006, at 11:42 AM, Simon Richter wrote:

> Mark Rustad schrieb:
>> There is a better way. Simply implement fork(). It can be done
>> even without an MMU. People think it is impossible, but that is
>> only because they don't consider the possibility of copying memory
>> back and forth on task switch. It sounds horrible, but in the vast
>> majority of cases, either the parent or child either exits or does
>> an exec pretty quickly, so in reality it doesn't cost much. The
>> benefits are many: being able to use real shells such as bash and
>> thereby being able to use real shell scripts.
> This imposes quite a significant overhead for the common case (in
> which the application has specifically requested that the parent
> process be terminated after the child process is fork()ed off).
> Even if the cost of transferring memory contents was cheap (which
> it isn't), you'd annoy the memory management subsystem unless you
> did a lot of weird tricks to avoid allocating from a large block.

Yes. I did not mean to suggest that vfork() should go away or that
shells that make use of it go away. It is just that making fork()
work has a lot of value. vfork() would always be the optimal thing to
use, but sometimes you need the power of a real fork(). Greater
compatibility with normal Linux is of greater value than adding more
funky special-purpose system calls.

>> You do have to look out for any applications that fork and do not
>> either exit or exec, but that is so much better than having to
>> modify so many things just to get them to run.
> Well, in fact just having a libc that does not define a symbol for
> "fork" and then going to the places the linker mentions as having
> undefined references is a pretty easy way. Mind you, in 90% of
> cases you can replace them by a vfork() and be done.

Yes, but some of those 10% cases can be a real pain. Also if you are
supporting users that just want some app to run, having fewer porting
barriers is a real help. Often the expense of fork() is only a
startup thing anyway and not a factor in the normal steady-state
operation of a system.

Mark Rustad,

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-11-20 21:51    [W:0.030 / U:2.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site