![]() | |||||||||||||
Messages in this thread |
Eric W. Biederman wrote: >>>Who do you report as the source of your signal. >> >>I've never dealt with signal enough from userspace to give you a good >>answer. Can you explain the mechanics of how you would go about doing >>this? > > Look at siginfo_t si_pid.... the siginfo is queued when a process is killed and si_pid is updated using the pidspace of the killing process. Processes parent of a pidspace are of a special kind : the init kind. >>>What pid does waitpid return when the parent of your pidspace exits? Well, a process doing waitpid on a parent of a pidspace, is not part of that pidspace so waitpid would return the 'real pid'. Am i getting your point correctly ? >>>What pid does waitpid return when both processes are in the same pidspace? hmm, please elaborate. There are indeed issues when a process is the parent of different namespaces. This case that should be avoided. >>>How does /proc handle multiple pid spaces? >> >>I'm working on it :) >> >>Right now, there's basically a hack in d_hash() to get new dentries for >>each pidspace. It is horrible and causes a 50x decrease in performance >>on some benchmarks like dbench. >> >>I think the long-term solution is to make multiple, independent proc >>mounts, and give each pidspace a separate filesystem view. That >>requires some of the nifty new bind mount functionality and a chroot >>when a new pidspace is created, but I think it works. > > I think you will ultimately want a new filesystem namespace > not just a chroot, so you can ``virtualize'' your filesystem namespace > as well. "virtualize" the mount points but not necessarily the whole filesystem. > I wonder if you could hook up with the linux vserver project. The > requirements are strongly similar, and making a solution that > would work for everyone has a better chance of getting in. We feel the same. C. - 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/ | ||||||||||||
| Last update: 2005-12-07 23:20 [from the cache] ©2003-2008 | |||||||||||||