Attach my own pid

Bernd Petrovitsch bernd at petrovitsch.priv.at
Tue Mar 22 06:25:13 EDT 2016


On Die, 2016-03-22 at 01:26 -0400, Valdis.Kletnieks at vt.edu wrote:
> On Mon, 21 Mar 2016 16:01:41 +0530, Nitin Varyani said:
> 
> > I am running a master user-level process at Computer 1 which sends a
> > process context like code, data, registers, PC, etc as well as *"pid"* to
> > slave processes running at other computers. The responsibility of the slave
> > process is to fork a new process on order of master process and attach *"pid"
> > *given by the master to the new process it has forked. Any system call on
> > slave nodes will have an initial check of " Whether the process belongs to
> > local node or to the master node?". That is, if kernel at Computer 2 pid of
> > the process is 1500
> 
> None of that requires actually controlling the PID of the child.

Well, I think that the OP wants to map the PIDs with a fixed offset per
host. So e.g. the local PID == 14 becomes 20014 on all other nodes.
At least for debugging it's easier than some random mappings;-)

As for top post: TTBOMK there is no SysCall for doing that.
* Perhaps one can achieve something similar with containers - one
  container per remote host or so (but I never used containers actively
  myself) or (ab)use KVM (does vServer still live?) for local
  "pseudo-VMs" (and use there the original PIDs - or so).
* The manual page of clone(2) doesn't reveal to me if it's possible to
  wish for a PID.
* You could clone (pun not intended;-) the fork() syscall and add an
  parameter - the PID - to it (and e.g. return -1 if it's already used).

BTW I don't know how the rest of the kernel reacts to such artifical
PIDs (but you will see;-) outside the "official range".

MfG,
	Bernd
-- 
"What happens when you read some doc and either it doesn't answer your
question or is demonstrably wrong? In Linux, you say "Linux sucks" and
go read the code. In Windows/Oracle/etc you say "Windows sucks" and
start banging your head against the wall."    - Denis Vlasenko on lkml





More information about the Kernelnewbies mailing list