Messages in this thread | | | Date | Mon, 20 Nov 2006 14:20:52 +0100 | From | Simon Richter <> | Subject | RFC: implement daemon() in the kernel |
| |
[please CC me on replies]
Hi,
I'm working with Linux on MMUless systems, and one of the biggest issues in porting software is the lack of working fork().
Except some special cases (like openssh's priviledge separation), fork() is called in mainly three cases:
- spawn off a new process, which calls exec() immediately
This can be easily replaced by a call to vfork(), which invokes the clone() syscall with the CLONE_VFORK flag.
- split off some work into a separate thread and provide address space separation
Since we don't have a MMU, there is no address space separation anyway, so we can replace this with a pthread_create(), which in turn calls clone().
- daemonize a process
There is a function called daemon() that does this; its behaviour is roughly defined by (modulo error handling)
int daemon(int nochdir, int noclose) { if(!nochdir) chdir("/");
if(!noclose) { int fd = open("/dev/null", O_RDWR); dup2(fd, 0); dup2(fd, 1); dup2(fd, 2); close(fd); }
if(fork() > 0) _exit(0); }
Since it calls _exit() right after fork() returns (so daemon() never returns to the calling process except in case of an error) it would be possible to implement this on MMUless machines if the last two lines could happen in the kernel.
I can see three possible implementations:
- "cheap" implementation
The process is assigned a new PID and the parent is pretended to have exited. There are a lot of pitfalls here, so it is probably not a good idea.
- a reverse vfork()
The child process is created and suspended, the parent continues to run until it calls exec() or _exit(). The good thing here is that it should be easy to implement as the infrastructure for suspending a process until another exits already exists.
- "normal" implementation
The child is created, the parent immediately zombiefied with a return code of zero. This might be more difficult to implement as the current implementation of fork() does not need to terminate a process in any way, so there might be funny locking and other issues.
Questions? Comments?
Simon - 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/
| |