Re: RFC: implement daemon() in the kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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, MRustad@mac.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux