Attach my own pid

Nitin Varyani varyani.nitin1 at gmail.com
Mon Mar 21 06:47:56 EDT 2016


A representative process, that is, a process without any user stack,
register values, PC, etc, with *"pid" *is maintained at the master node.
Now, the process which was migrated to a remote node, in this example
Computer 2, and having process id *"pid", *decides to fork(). It is a
system call and is forwarded in the same way to master process. This
request is forwarded to the representative process with process id *"pid"*.
The representative process forks() leading to a new representative process
with process id *"cpid". *This "cpid" is forwarded to master process which
forwards it to slave process. The slave process forwards *"cpid"* to the
remote process with process id *"pid"*. The remote process with process id
*"pid"* now forks a child and attaches *"cpid" * to its child.

This is overview of what I want to achieve. A small correction in my last
mail.

.....Continued.... That is, if kernel at Computer 2 finds that pid of a
process requesting a system call is 1500, the request is forwarded to slave
daemon which in turn contacts with the master daemon. Master daemon
forwards this information to corresponding representative process which
requests the kernel for the system call and sends the result back to slave
daemon.

On Mon, Mar 21, 2016 at 4:03 PM, Nitin Varyani <varyani.nitin1 at gmail.com>
wrote:

> .....Continued.... That is, if kernel at Computer 2 finds that pid of a
> process requesting a system call is 1500, the request is forwarded to slave
> daemon which in turn contacts with the master daemon. Master daemon
> requests the kernel for the system call and sends the result back to slave
> daemon.
>
> On Mon, Mar 21, 2016 at 4:01 PM, Nitin Varyani <varyani.nitin1 at gmail.com>
> wrote:
>
>> I am trying to create a distributed pid space.
>>
>> 0 to 2000 Computer 1
>> 2001 to 4000 Computer 2
>> 4001 to 6000 Computer 3
>>
>> and so on...
>>
>> 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
>>
>>
>>
>> On Mon, Mar 21, 2016 at 12:23 PM, <Valdis.Kletnieks at vt.edu> wrote:
>>
>>> On Mon, 21 Mar 2016 10:33:44 +0530, Nitin Varyani said:
>>>
>>> > Sub-task 1: Until now, parent process cannot control the pid of the
>>> forked
>>> > child. A pid gets assigned as a sequential number by the kernel at the
>>> time
>>> > the process is forked . I want to modify kernel in such a way that
>>> parent
>>> > process can control the pid of the forked child.
>>>
>>> What does controlling the pid gain you?  To what purpose?
>>>
>>> > Sub-task 2: On Linux, you can find the maximum PID value for your
>>> system
>>> > with the following command:
>>> >
>>> > $ cat /proc/sys/kernel/pid_max
>>> >
>>> > Suppose pid_max=2000 for a system. I want that the parent process
>>> should be
>>> > able to assign a pid which is greater that 2000 to the forked child.
>>>
>>> Again, why would you want to do that?
>>>
>>> Anyhow...
>>>
>>> echo 3000 > /proc/sys/kernel/pid_max
>>> fork a process that gets a pid over 2000.
>>>
>>> Done.
>>>
>>> Note that on 32 bit systems, using a pid_max of over 32768 will cause
>>> various things in /proc to blow up.
>>>
>>> I suspect that you need to think harder about what problem you're
>>> actually
>>> trying to solve here - what will you do with a controlled child PID? Why
>>> does
>>> it even matter?
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160321/8087ab47/attachment.html 


More information about the Kernelnewbies mailing list