On Mon, Jul 5, 2010 at 12:10 AM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: > On 07/04/2010 04:39 PM, Matt Helsley wrote: >>> >>> 1. can you implement it for i386 (register starved) using eclone? >> >> That's a very good question. I'm going to punt on a direct answer for >> now. Instead, I wonder if it's even worth enabling vfork through eclone. >> vfork is rarely used, is supported by the "old" clone syscall, and any >> old code adapted to use eclone for vfork would need significant >> changes because of vfork's specialness. (A consequence of the way vfork >> borrows page tables and must avoid clobbering parent's registers..) > > vfork is its own system call for a reason. We used to do it with > sys_clone, and it turned out to be a mess. Doing it in a separate > system call -- even though the internals are largely the same -- is cleaner. That's interesting; only ia64 and xtensa still do vfork via clone. I remember sys_vfork being purely i386. I guess we need an evfork then. We're slowly gaining all sorts of functionality (various clone flags) that is inaccessible when there is a need for vfork behavior. To greatly reduce the mess, I strongly suggest that it have the int(*func)(void*arg) and void*arg arguments like BSD's rfork_thread. Note that this mess reduction would be severe enough to solve the problems with sharing a syscall. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
