Messages in this thread | | | Date | Tue, 15 Nov 2005 07:32:22 -0600 | From | "Serge E. Hallyn" <> | Subject | Re: [RFC] [PATCH 00/13] Introduce task_pid api |
| |
Quoting Paul Jackson (pj@sgi.com): > > But in the end isn't that more complicated than our approach? The > > kernel still needs to be modified to let processes request their pids, > > No - getpid() works, as always. Perhaps I don't understand your > comment. > > > > and now processes have to worry *always* about the value or range of > > their pids, both at startup and restart. > > No - tasks get the pid the kernel gives them at fork, as always. > The task keeps that exact same pid, across all checkpoints, restarts > and migrations. Nothing that the application process has to worry > about, either inside the kernel code or in userspace, beyond the fork > code honoring the assigned pid range when allocating a new pid.
Ok, so we have fork code to dole out pid ranges per vserver, I see where the app doesn't need to request a pid on startup. But what about restart? Surely the app still needs to be restarted with the same pid - just that now we are more trusting that the pid remains available bc of the pid ranges?
> No wide spread kernel code change, compared to yours. As now, tasks
Note that while the patch is large, so far its main purpose is to introduce a clean concept rather than hack the vpid idea in. The latter has beem done before, and only requires intercepting the points where pids go from user to kernel. This leaves the question of which pid is which more ambiguous.
-serge
- 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/
| |