On 25/01/16 16:50, [email protected] wrote:
Hey Antti,
thank you so much! :) I tested with a similar command but didn't guess right
the process ID (tried 0 and 1).
Next time write a script to search the pid space ;)
For general reference, proc0 is for the kernel threads, proc1 is for
implicit local processes (a concept which is not really relevant for
Rumprun). Years ago they used to be the same proc, but them someone
called setuid() from an implicit application process, and funny things
happened due to kernel threads suddenly having only user privileges. So
I decided maybe it's better to put them into separate processes to
prevent that non-obvious failure mode (and other similar ones).
The rest of the pids are for applications. I guess it's strictly
speaking not guaranteed that NetBSD won't change the pid allocation
algorithm to be something else than the current one, but the odds are
fairly low. Pids also don't go sequentially all the way to up PID_MAX.
I don't remember off the top of my head where they deviate, but in
case someone really wants to know, it's easy to write a program which
calls getpid() and rump_pub_lwproc_rfork() and _release() in a loop.
Note that each rumpctrl remote process gets its own pid. So if you have
a multibaked guest where the first proc isn't run "instantaneously", any
remote processes you run against the server while the first proc is
running will bump the pid of the second proc. Hmm, I guess
theoretically you can attach remote processes also before the first proc
runs...
