Attach my own pid

[Nitin Varyani]

struct task_struct {
volatile long state;
void *stack;
...
*pid_t pid;*
...
}
You mean to say that just mapping the *pid_t pid*  will do the job. Does
the linux kernel not store pid somewhere else while forking a child?

On Mon, Mar 21, 2016 at 4:18 PM, Pranay Srivastava <pranjas at gmail.com>
wrote:

> Nitin,
>
>
> 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.
>
> I don't think doing this by pid is better. It might suit you currently
> but in the long run?
> If you are able to send the whole context, why not map that pid to
> your context internally instead of relying
> on pid which is also visible outside your context.
>
> >
> > 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
> >>
>
> your pid 2000 shouldn't have to be same pid 2000 on another node. You
> just need the context right?
>
> >> 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?
> >>
> >>
> >
> >
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
>
>
>
> --
>         ---P.K.S
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160321/c924efa4/attachment-0001.html